Technical Deep Dive from AWS Support Series [3] BigData Profile 編

■プロフィール

アマゾンウェブサービスジャパン合同会社 サポートエンジニアリング

Hori ： クラウドサポートエンジニア（BigData Profile）

Tateno ： シニアクラウドサポートエンジニア（Database Profile）

はじめに

こんにちは、Technical Deep Dive from AWS Support Series の 3回目となります。今回もインタビューはSenior Cloud Support EngineerのTatenoがつとめます。それでは、早速自己紹介いただけますでしょうか。

よろしくお願いします。 Hori です。入社前にデータベース管理などを中心とした業務経験があったので、入社後はDatabase Profileでデータベース関連のお問い合わせを中心に対応していました。その頃から、データベースに蓄積されたデータの利用にも関心があり、Hadoopをはじめとしたビッグデータ技術にチャレンジしたい気持ちがありました。その後、プロファイル異動をしまして、現在は BigData Profile で AI/ML や分散処理を学びつつお客さまのお問い合わせの対応をしています。

ありがとうございます。このプロファイルを移られた経験って、仕事に役立ったりといったことはありましたでしょうか。

新しい領域のチャレンジとなるので、学ぶことが多くあり大変ではありましたが、新しい知識や経験ができるので、良かったと思っています。 学習面ではデータベースの知識や経験が活かせる場面もありました。 例えばトランザクションログ (Write Ahead Log) などの仕組みはさまざまなところで使われており、学習の際の理解の助けになっています。 また、データベースの考え方や仕組みは昔から使われている安定したものが多い認識ですが、この仕組みでスケールすることが難しいという課題からビッグデータのデータ処理で新しい技術が考えられているケースもあるので、実感をもって理解しやすいという点もありました。データベースそのもの以外でも、データベース周辺技術でネットワーク周りの知識やストレージの知識なども、再利用できる知識で役立ちました。

ありがとうございます。Database Profile と BigData Profile の間では、データを扱うという意味で、様々な共通技術があるなと、私も常日頃から感じております。

AWS Glue について

それでは、今回 AWS Glue についてお話しいただけると伺っておりますので、まず最初に、AWS Glue について簡単にご紹介いただけますでしょうか。

AWS Glue は複数のデータソースからデータを簡単に検出、準備、移動、統合できるようにするサーバーレスのデータ統合サービスです。例えば、出力先として一般的なリレーショナルデータベースのように構造化データとして格納したいけれども、元のデータソースが半構造化テキストデータであるような時に、ETL (Extract Transform Load) 処理を行い構造化データに変換することができるサービスです。

ありがとうございます。次に、AWS Glue に馴染みのない方も多いと思いますので、ぜひ簡単に AWS Glue の仕組みについてご紹介いただければと思います。

AWS Glueの大まかなコンポーネントについて説明します。

まず、クローラー (Crawler) は、データソースをクローリングし、自動的に推測したスキーマ構成をデータカタログにテーブルとして記録します。このデータカタログ (Data Catalog) とはテーブルなどのメタデータ情報を保管するメタデータストアです。メタデータなので実データはありません。テーブルとはリレーショナルデータベースの Create Table DDL クエリで指定するカラム名と型などの情報を持っているもの、とイメージするとわかりやすいかと思います。次に、ETL ジョブでは、データカタログに登録されたメタデータ情報を利用してデータソースに接続し、データを変換するといったことが可能です。
流れとしては、クローラを使用してジョブで処理を行いたいデータソースとターゲットをクローリングし、データ型などのスキーマ情報やデータの格納場所、SerDe (Serializer/Deserializer) などのメタ情報をデータカタログにテーブルとして登録します。ETL ジョブではデータカタログに登録されたテーブルの情報をもとにデータソースのデータをターゲットの型やフォーマットに合う形に変換してターゲットにロードする、という流れとなります。

お客さまからのお問い合わせについて

サーバーレスで ETL を実施できるのは素敵ですね。ありがとうございます。それでは次に、今回のお話では、お客さまからどのようなお問い合わせを受けられましたでしょうか。

今回ご紹介するお問い合わせの内容は、Amazon DynamoDB のテーブルをクロールしデータカタログにテーブルを作成してある状況で、Visual Editor という機能で DynamoDB テーブルのデータを CSV に出力する ETL ジョブを作成して実行した際にエラーとなったという状況であり、エラーの原因と対策について教えてほしいというお問い合わせとなります。エラーメッセージにて「An error occurred while calling o95.pyWriteDynamicFrame. Cannot write set Field fruits to CSV」といったメッセージが見受けられており、データの変換で失敗していると考えられる状況でした。

ETL ジョブ上で、データの変換をするときにエラーが出ているという種類のお問い合わせだったんですね。となると、先ほどご説明いただいたアーキテクチャーから考えて、お客さまの課題をどのように理解されましたでしょうか。

お問い合わせの文面から、お客さまの本当に解決されたい課題は、「DynamoDB テーブルから、データを CSV に変換して出力したい」であると読みとりました。今回は課題が明瞭ですが、例えば、不明点がある場合はヒヤリングし明確にするためのコミュニケーションをお客さまと行います。続いて、お客さまの課題から、このお問い合わせで我々がご案内するべき内容を考えます。まず、エラーの調査をご希望ですのでエラーの調査結果は必要です。お客さまが本当にやりたいことは、DynamoDB テーブルのデータを CSV に出力すること、ですので、ジョブがエラーにならずに、CSV に出力できるような方法をご案内する必要がありそうです。

課題の深掘りについて

となると、この課題を解決するため、どのように深掘りを進められましたか。

今回は、エラーメッセージとジョブラン ID という、ジョブ実行時の固有の ID をいただいています。我々サポートエンジニアは、内部ツールから様々な情報を確認することが可能であり、ジョブラン ID から当時の状態を確認し、実行ログにアクセスすることができます。まずは、内部のツールを使って、当時の実行環境実行ログの確認を行い、情報を収集します。今回は内部ツールで確認したログから、スタックトレースが確認できました。
エラーメッセージが出力されていそうな処理を特定し、サービスのソースコードからエラー箇所を確認すると、変換対象のデータのフィールドに、Set 型や Map 型がある場合には CSV に変換できないメッセージを出力していました。直感的にも Set 型や Map 型といったデータ構造は、そのまま CSV にするイメージが湧きません。これらのデータ型は事前に変換処理を行う必要があります。
今回はお客さまのデータソースが DynamoDB テーブルとのことで、類似の環境が作成できそうであったため、実際に再現確認を試みました。DynamoDB テーブルに Set 型のアイテムを格納し ETL ジョブで CSV に変換を行うと事象が再現しました。これで原因はほぼ特定できたと考えられます。対策としては Set 型をフラット化する方法となると考えられたので、フラット化処理を追加して、再度ジョブを実行したところ、期待通りに CSV 出力できたことを確認しました。

Set 型というのは、仕様上、CSV には変換できないということですね

そうですね。下記の図の上段のように、Set 型などの複数の要素で構成されている型をCSVにするには内包する要素を取り扱うことが難しいかと思います。下段のように Set 型の要素を抽出して、それぞれ別の列のデータとなるようフラット化を行うことを今回の対処として考えました。

このフラット化という処理は、どのように実現できるんでしょうか。

フラット化を行うには、言語によっては便利なメソッドとしてフラット化を行う手法が用意されている場合もありますが、一般にはループ処理で各要素を取り出して別の列として扱うようにプログラムを書くことになるかと思います。実は、AWS Glue サービスでは、マネージドに提供している便利な変換の機能があり、フラット化も簡単に行えるようになっています。今回のケースでは、このマネージドの仕組みをご案内しております。

ありがとうございます。スタックトレースからエラーが発生した場所とエラーの種類を分析し、そこから考えられる対処を導きだして問題解決されたわけですね。今回は、メッセージから論理的な思考で問題を見通せたと思うのですが、より複雑な問題ですと、調査に時間がかかるとか、それ以前に事象の再現までなかなか見通せない場合もありうると思います。そういった場合、どのように対応されますか。

結構難しいところがあって、元からトラブルシューティングはお客さまと二人三脚で取り組む必要がありますが、お客さまのデータに依存している場合など、再現環境の作成が難しいケースでは、さらに密な連携が必要となります。お客さまの環境でしか試せない状況となるので、慎重にエラーメッセージなどの断片的な情報から問題を掘り下げ、仮説を立てて回避策などの模索を行います。
再現環境の作成が難しいケースの例としては、パフォーマンスの問題があります。お客様の環境のデータやコードに依存する場合、再現環境が作れないケースもあります。そのような場合に役立つ情報として、AWS Glue の Spark Job パフォーマンスチューニングに関する情報がまとまっている「AWS Glue Apache Spark ジョブのパフォーマンスチューニングのベストプラクティス」というドキュメントがあります。パフォーマンスの問題のアプローチや考え方についても記載されているので、パフォーマンスにお悩みの際にはご一読いただくとよいかと思います。
また、私たちは、原因がわからなくても回避策をご案内できることが重要であると考えており、できるだけ早いタイミングにて、お客さまのシステムをちゃんと動くようにしたいというところがあります。ビッグデータ関連のサービスは多くのサービスと統合されているものもありますので、他のサービスや仕組みを使って回避策をご案内することは、大切だと考えています。

ありがとうございます。課題を根本的に解決をするのと同じくらい、できるだけ早くいまお客さまがお困りの事象を緩和することも、我々技術サポートにとっては大事ですよね。とても共感します。ということで、今回 BigData Profile より Hori さんに AWS Glue のトラブルシューティング例を伺いました。ありがとうございました。

ありがとうございました。