デザイン＆エンジニアリング部の大和です。
システム構成図・アーキテクチャ図なんて呼ばれるものを考えたり描いたりすることを生業としています。
在宅ワーク・通販に加えて最近宅食サービスというものを覚えてしまい、いよいよ外出する機会が飲み会しかなくなってしまいました。
これは年明けの貴重な外出日に食べた、分かる方には分かる縁起物の写真です。

一蘭・二郎・三田製麺（一富士二鷹三茄子）

さて今回は弊社のサービス開発案件で採用した経験を踏まえ、AWS Glueについて、その振り返りと次案件でAWS Glueを採用するときのポイントになりそうな特徴をご紹介します。

はじめに結論

次を満たすシーンで、AWS Glueを積極的に採用できると結論付けました。
  • スケジュール面
    • とにかく短納期でバッチを作りたい
    • ライトに開発をスタートしたい
  • 機能面
    • 処理フローをある程度の細かさに分割できる
    • 複雑な条件分岐がない、などある程度単純な処理である
  • 要員面
    • 各開発者はAWS初心者でもOK
    • AWS全体を管理するITアーキテクトとして、それなりにAWSが分かっている人がいて全体の面倒を見られる

逆に、どれかを満たさないシーンでは、後述のメリット・デメリットと照らしてAWS Glueを採用するべきか慎重に検討する必要があると言えます。

それでは、実案件の経験を踏まえたAWS Glueの紹介に入ります。

今回AWS Glueを使ってやったこと

実績

今回AWS Glueを採用した案件の、簡単なサマリです。

  • CSVファイルをAWS Glueジョブで加工・集計してAmazon QuickSightで可視化するシステム
  • 機能数はAWS Glueだけで40ジョブ
  • リーダ・ITアーキテクトを除くと開発者は新卒1−3年目の若手5名
  • 設計開始からリリースまで2ヶ月

それなりに多い機能数を、若手だけで、短期間で開発できたことが、
AWS Glueだからこそ得られた成果であると思います。

今回作ったアーキテクチャ

開発イメージを補足するために、今回作ったシステムの一部を簡略化したアーキテクチャ図を添えます。

AWS Step Functionsによるジョブフロー実行や、全体をAWS CloudFormationでデプロイしたことなどは本記事では割愛します。

AWS Glueの特徴

AWS Glueについて

AWS Glueは、公式ガイドの通り大量データの扱いに長けたサーバレスのコード実行基盤サービスです。
AWS Glue Data Catalogやクローラーといった関連サービスを駆使して、Amazon S3やRDBMSサービスなどのデータソースから大量データを取得して加工・集計といった処理を行うことができます。
今回は一度に数千〜数万行のCSVデータを外部API通信込みで1時間以内に処理するバッチを実装しましたが、Glueのジョブには最大100DPU（1DPU=4vCPU+メモリ16GB）までリソースを設定できるため、GB単位やそれ以上の大量データを扱うことができます。
詳細は公式ガイドを参照ください。

AWS Glue Studioについて

AWS Glue Studioは、AWSマネジメントコンソールにログインすることでブラウザ上での開発ができるGUIサービスです。
いわゆるETLツール（データの抽出(extract)・変換(transform)・書き出し(Load)を行うツール）のような見た目で、データソースの読み込みやJOINといった一般的な処理は既に用意されておりコードレスで実装できます。
用意されていない複雑なロジックは、Scala/Pythonを直接コーディングして組み合わせることもできます。

メリット・デメリット

メリット

今回、AWS Glueを採用して感じたメリットです。

比較対象は、AWS LambdaやAmazon EC2に対して同等のアプリケーションを構築するケースです。

開発が早い

今回の開発は短納期だったため、ローカルPCでは一切コーディングをせず全てAWS Glue StudioのGUI上で開発を行いました。
これによって、手順書に従って数時間かけてローカル環境構築を行う必要がなく、開発中期に参画したメンバも即日開発に着手できました。

また、ETLベースの開発のため直感的・視覚的に処理と処理を繋げることができ、若手メンバでも容易に開発を進めることができました。
レビューも、視覚的に処理の流れを追うことができるため短時間で済ませることができたと開発リーダからフィードバックを受けています。

プログラミング工程で気になるデバッグについても、AWS Glue Studioにはデータプレビュー機能がありコストはかかりますが常にデータを読み込ませて今書いたコードの処理結果を確認できます。

関連サービスとの接続が豊富

大量データの扱いに長けているAWS Glueの特性から、

  • データ入出力：Amazon S3上のCSV, JSONファイル、Amazon Redshift、Amazon Athenaなど
  • 実行管理（ジョブフロー）：AWS Glue ワークフロー、AWS Step Functions
  • 他サービス呼出し：AWS Secrets Managerなどの他サービスも、IAM Roleの権限を用いてScala/PythonのコードからAWS SDKで呼出し可能

といった関連サービスとの親和性が高く、AWS Lambdaに劣らない自由度があります。

デメリット

メリットの一方で、AWS Glueならではのデメリットであると感じたことをまとめます。

実装上の制約がある
影響：方式設計の見直し・生産性低下

  • GUIに用意されたJOINやUNIONは内部的にAWS Glueが独自拡張したPySparkで実装されることがあり、これが0件データを処理しようとするとエラーで落ちます。幸い今回は0件データでジョブが落ちてもジョブフロー全体は続行可能だったため、AWS Step Functionsでエラーを制御することで対処できました。
  • AWS Glueは大量データを読み込む際に、最初の100件を先行ロードして型判定を行います。よって特定の列が最初の100件全てで空の場合に型定義エラーが起きるため、空データを示す特定文字で値埋めを行う必要がありました。
  • AWS GlueはAWS Glue Data Catalogに対して日付型で出力できますが、そのカタログから日付型を読み込んでも文字列として認識してしまうため、Scala/Pythonコードで型変換が必要でした。

長大なETLになるとデータプレビューが長い
影響：生産性低下

  • ETLの処理が3,4つしかない状態でもデータプレビューに20～30秒かかり、数十にもなるとデータプレビューが表示されるまで5分前後待つことになり、開発後期ではバグ修正のボトルネックとなりました。

      従量課金型APIをデータプレビューで呼び出すとクラウド破産する
      影響：想定外の課金の発生・生産性低下

      • データプレビュー機能を有効にしていると、数回再読み込みしただけで、ETLの複雑性（分岐の数）によっては数十回処理が実行されます。実際に、10件のテストデータをデータプレビューして開発していたら5分程度で数百回APIがコールされていました。例えば$10/1,000回のGoogle Maps APIを使用していた場合、1日の内に数千円・数万円の課金が発生するでしょう。
        今回の案件では「課金APIを呼ぶコード箇所は、APIの動作確認目的以外ではコメントアウトする」「APIキーはAWS Secrets Managerで管理し、普段はAWS Secrets Manager上の値をダミー値にする」の両方の対策を取ることで想定外の課金が発生することを防止しましたが、開発しづらいと感じた部分でした。

      その他の注意点

      デメリットとは異なり対処は可能ですが、注意が必要な点がありました。

      AWS Glue Studioだけでは自動テストができなかった

      • ローカル環境と組みわせることで自動テストができることは公式ガイドでも紹介されていましたが、今回は期間的にGUIに限定して開発を進めたため、自動テストを諦めました。次は導入したいです。

      「マスタ」テーブルに対してもJob Bookmarkが効いてしまう

      • AWS Glueの利点であるJob Bookmark機能（処理済みデータをマーキングし二度処理しないようにする機能）が、マスタテーブルにも効いてしまうため、マスタテーブルの読み込み箇所だけBookmark情報を削除（公式ガイド）する必要がありました。これはGUI上ではできないため、一度GUIから生成されたコードをダウンロードして直接編集する運用になりました。

      AWS Glue Data CatalogでCSVファイルを読み込む場合に注意が必要

      • CSVファイルを読み込む際に囲い文字（””）を省くためにはOpenCSVSerDe（公式ガイド）を使う必要がありますが、これは日付情報を整数値で持つ必要がありScala/Pythonコードで都度変換することになりました。また、今回Amazon Athenaと組み合わせましたが、Amazon Athenaがコスト削減のため推奨するパーティション分割も、数値型で日付情報を持っているため日付ベースのパーティションは作らないことにしました。

        共通処理をGUI上で実装できない

        • GUIの機能だけで、ジョブAとジョブBで共通な処理部分を切り出してA, Bから参照するといった共通機能化はできませんでした。zip圧縮したPython, Jarファイルをロードすることはできるため、共通処理を一度ローカルPCでzip圧縮してAmazon S3にアップロードして参照する、といった方式を採用しました。

        おわりに − 次案件で取り組んでみたいこと

        今回の開発で、AWS Glueのメリット・使い所はある程度見られたと思い、次案件でもマッチすれば採用したいと考えています。

        そこで課題となるのがデメリットや注意点ですが、次案件では、これらを対処療法ではなくきちんと解決できるような開発フロー・アーキテクチャ図を描いてみたいと思います。

        最後に、今回の案件で使用した、AWS Glue Studioでのコーディングガイドとレビュー観点を次ページ以降に添えます。次案件でブラッシュアップしたら、またFintanにてご報告したいと思います。