AWS EMRとAmazon S3への移管で「複雑データの処理高速化」と「システムコスト最適化」
幸いにもb→dashは順調にサービスを拡大することが出来ましたが、拡大していくと同時に、当時のAmazon Redshiftの利用方法では限界があることもわかってきました。
b→dashの利用企業が増えたことで、それまでの企業とは異なる形式でデータを保存している企業も増加したため、より一層複雑にデータを組み合わせて集計する必要がありました。
取り扱うデータ形式の種類が少ないうちは、Amazon Redshiftのクラスタ上でスキーマを適切に設計することで大量なデータでも高速に処理できていましたが、データの形式が多岐にわたるにつれてクエリや計算処理も複雑化し、集計時間が長くかかるようになってきました。また、保持するデータ量に比例して、Amazon Redshiftのクラスタをスケールアップする必要があったため、システムコストも右肩上がりで増えていました。
多様なデータ形式でも高速に処理するにはどうすればよいか？という点を再度AWSのソリューションアーキテクトの方とも相談した結果、Amazon S3とAmazon EMRを駆使すれば実現できるのではないか、という解にたどり着きました。
Amazon Redshiftは、データの保管と処理を同じシステム内で実行するのですが、データの保管はAmazon S3、データの処理はAmazon EMRと分離することで、複雑なデータをより高速に処理できると考えました。具体的には、一旦全てのデータをAmazon S3にORC形式で保管し、Amazon EMR上のHiveやPrestoといった分散処理エンジンから、Amazon S3のデータを参照し処理する、という方法に変更しました。
これによって、異なる形式のデータを無理に1つのRedshiftクラスタ上に持つのでなく、データ形式や分散処理の種別に応じてAmazon EMRのクラスタを適切に分けることができるようになります。こうして、データ形式の異なる処理を高速化することができました。
また、Amazon Redshiftは常時起動しておく必要があり、起動している時間だけシステムコストが発生していましたが、Amazon EMRとAmazon S3は必要なときだけ起動・アクセスすればよく、起動時間が短くなった分、システムコストを最適化することもできました。
AWSに独自サービスを付け加えることでより安定したシステム基盤を構築
ただ、Amazon EMRの利用において苦労した点もありました。それは、分散処理の不安定さです。
分散処理では、クラスタを構成するインスタンスのうち1台でも障害が発生したら、クラスタの処理全体に影響を及ぼしますし、複数の処理を同時に走らせたときに、内部処理で一時的にリソースが枯渇して処理が落ちるという特有の問題も発生してしまいます。
そこで、b→dashにおいては、Amazon EMRのスケーリングや処理の割り振りを動的に管理するリソースマネージャーという独自サービスを構築し、この問題を解決しました。
リソースマネージャーの役割は大きく3つあります。1つ目は、Amazon EMRで処理を実行するときに、処理を割り振るクラスタを動的に決めること。2つ目は、Amazon EMRのCPUやメモリといったリソースの仕様状況に応じて、自動的にクラスタの台数をスケーリングさせること。3つ目は、不具合が発生したクラスタがある場合に自動的に検知し、再起動をかけて自動的に復旧を行うことです。
リソースマネージャーによって、不安定な分散処理を安定的にかつ効率よく行うことができるようになり、コストと安定性の両立を行うことができるようになりました。
まとめ
AWSのサービスは多岐にわたり、それぞれ特長が異なります。状況に応じていかに適切なアーキテクチャを組むか、という点が重要と考えています。
b→dashの場合、リリースして間もないころは、クライアント数も多くなくデータ形式の種類も多くはなかったため、それらを1つのクラスタ上でデータを高速に処理できるAmazon Redshiftを選択しました。それから数年経つと、利用企業数も増え、その分処理するデータ形式の数も多種多様に増えていったため、複雑なデータ処理を高速でできるAmazon S3とAmazon EMRへとアーキテクチャを進化させました。このようにサービスの状況に応じて最適なアーキテクチャは何か？という点を常に見直していくことは大事だと思います。
AWSのサービスも、時代に合わせて常に更新されているので、今後も最新情報をキャッチアップし、今のb→dashにとって最適なアーキテクチャが何か？ということを今後、私自身も自問自答し続けていきたいと考えています。
AWSソリューションアーキテクトより一言
フロムスクラッチのAWSサービス活用のここがポイント！
フロムスクラッチさんは、ペタバイトレベルの膨大なデータ量と顧客ごとに異なるデータ形式という複雑さに対して高速な処理スピードと高いコスト効率を実現し、さらに分散処理の安定化など、ビジネス価値に直結する技術課題を明確にした上で技術を選択されています。そして、CTO井戸端さんが「サービスの状況に応じて最適なアーキテクチャは何か？という点を常に見直していくことは大事」と書かれている通り、柔軟にアーキテクチャを進化させてビジネスの成長を加速している点も素晴らしいと思います。さらに成長を続けるフロムスクラッチさんが、次にどのような課題に対して、AWSサービスを活用するのかが楽しみです。
