AWS上で構築するサーバレスアーキテクチャの設計と運用

株式会社カンリー

「店舗経営を支える、世界的なインフラを創る」をミッションに、店舗事業者向けの集客支援サービスを提供しています。
本稿では、集客支援の主力プロダクト「カンリー店舗集客」で採用している、サーバレスバッチ処理のアーキテクチャをご紹介します。

サーバレスのインフラアーキテクチャについて

背景

「カンリー店舗集客」は2020年にサービスをリリースし、現在では導入店舗数が11万店を超えるプロダクトへと急成長しています。
急成長の裏側では、スピード優先の開発によって技術的負債が蓄積され、運用保守が難しくなっていました。インフラ面でも課題が多く、当時はEC2を採用していたため、1つのバッチに突発的な負荷がかかると、同一ホスト上で稼働していた他のバッチ処理もすべて停止してしまうことがありました。

また、バッチの成功／失敗の把握が難しく、並列処理がアプリケーションコードに依存していたことや、インスタンスの常時稼働によるコストの高さも課題でした。

解決策

これらの課題を解決するため、EventBridge、Step Functions、AWS Batch を組み合わせたサーバレスなバッチ処理アーキテクチャへと移行しました。
従来はEC2上のcronでバッチをスケジューリングし、実行タイミングを環境変数で制御していましたが、EventBridgeを用いることでサーバレス化し、他のAWSサービスとの連携も容易になりました。

EventBridgeからはStep Functionsが呼び出されます。Step Functionsはサーバレスなワークフローサービスで、GUI上で各ステップの実行状況が可視化されるため、どこで失敗したかを直感的に把握でき、トラブル対応がしやすくなっています。また、処理対象のデータをCSVに出力して全く同じ条件で再実行できる工夫や、Mapステートによる並列処理で拡張性も確保しています。

実際のバッチ処理は、Step FunctionsからAWS Batchを通じて実行され、Fargateをコンピューティングリソースとして利用しています。これにより、EC2のように常時インスタンスを起動しておく必要がなくなり、コスト削減が実現しました。OSやミドルウェアの管理も不要となり、運用負荷も大幅に軽減されています。さらに、ジョブごとにCPUやメモリのリソースを柔軟に調整できるため、1つのバッチ処理が他の処理へ与える影響も限定的になりました。

CI/CD

StepFunctionsやAWS Batchの枠組みのみTerraformで管理しています。一方で、Step FunctionsのASL（Amazon States Language）、ジョブ定義、EventBridgeのスケジュールなど、アプリケーションに密接に関わるリソースについては、Terraformの管理外としています。これらはアプリケーション側で管理し、CI/CDのワークフローでアプリの変更と連動して自動更新しています。

監視

Step Functionsの失敗イベントはEventBridgeバスを通じてDatadogに送信され、Datadogではイベントモニターにより監視されています。

課題

移行後の課題としては、Step FunctionsのASLに慣れるまで時間がかかる点が挙げられます。この対策として、社内で勉強会を実施し、その様子を録画して新規メンバーがキャッチアップできるようにしています。

また、1分間隔で実行するようなショートポーリング系のバッチは、このアーキテクチャが適していないという課題もあります。こうしたケースはLambdaの活用など、今後の改善が必要だと考えています。

今後の展望や取り組み予定について

拡張性と可用性を確保した構成は実現できたものの、バッチの実行状況を一覧で把握したり、失敗ジョブのリトライや一括停止を誰でも容易に行える運用環境の整備が今後の課題です。現時点ではバッチの数や依存関係は比較的シンプルですが、将来的な増加を見据え、運用性とオブザーバビリティの向上に取り組んでいく予定です。Datadogにはすでにバッチのログを送信しており、今後はAPMを導入し、より深い可視化を目指しています。

サービスがグロースしていく過程で複雑さが増していくことは避けられません。そうした中で、機能開発を優先しながらも運用の手間を抑えるには、今回のバッチに限らず、やはりサーバレス構成が有力な選択肢になると考えています

◆執筆：株式会社カンリー プラットフォーム部 SRE 本間 雄基
@paya02_ictdev

株式会社RevComm

音声コミュニケーションの課題をテクノロジーで解決するSaaS「MiiTel（ミーテル）」を開発・提供しています。営業・サポートなどのビジネス通話における内容を可視化・解析することで、チームの生産性向上や業務改善を支援しています。

MiiTel Scan to Callについて

従来の通話方法における手間やコストを削減し、新たなコミュニケーション体験を提供したいという思いから、「MiiTel Scan to Call」を開発しました。

「MiiTel Scan to Call」はスマートフォンでQRコードをスキャンするだけでアプリインストールや特別な設定なしにブラウザからすぐに無料で通話を開始できるサービスです。

サーバレスのインフラアーキテクチャについて

どのような形でサーバレスアーキテクチャを導入・活用しているか

全く新しいサービスなので早く世に出してフィードバックをもらいたかったため、なるべくシンプルにコストをかけずに早く構築することを考えてサーバーレスを導入しました。

既存のプロダクトと重なる部分（認証、データベースなど）があったため完全にシンプルなサーバーレスアーキテクチャとすることはできなかった。CloudfrontやRDSの採用、VPC内にLambdaを置いているなどはこれが理由です。

また、将来サービスが伸びたときサーバーレスではない選択肢を取りやすくできるようにコンテナ内にWebアプリケーションを立てるという形を採用しました。

当初設計していた時はなるべくインフラコストをかけないことを考えていましたがレスポンス速度などの改善のために一定コストをかけるという方向に舵を切りました。それでもECSなどと比べると圧倒的に安いです。

設計や運用における工夫・課題とその解決策

アーキテクチャ設計やCI/CD、ローカル開発、セキュリティ、監視、トラブル対応など、日々の運用で直面している／していた課題と、それに対する工夫や捉え方などを項目別にまとめると、下記になります。

レスポンス速度の改善

• Cold Startの回避
  • Provisioned Concurrency はコスト面での懸念がありましたが、コンテナが軽量であることと実行時間、頻度を考慮するとScan to Callではコスパの良い手段でした。
• シークレットの読み込み
  • リクエストが来た時にSSMから都度読み込まなければならなかったので時間がかかっていました。キャッシュ導入と一括取得で対応しました。
  • LambdaとRDSの接続管理
  • RDSとの接続をプールしておくためにRDS Proxyを間に挟みました。
• メモリ増強
  • Lambdaの課金体系はメモリ量×実行時間によって決定されます。メモリ量は増えましたが実行時間を短縮できたのでコストも抑えたまま改善できました。

Lambda上でのWebアプリケーションフレームワークの扱い

• ローカル開発をしやすくするために、またLambda以外に移行したくなったときに早く移行できるようにコンテナ上にWebアプリケーションを構築するという形を採用しました。Lambda Web AdapterというLambdaの拡張機能を使って実現しています。

その他

• 元URL（ホスト名）が取れない
  • ヘッダに付与するcloudfront functionを用意してホスト名をWebアプリケーション内やログで使えるようにした。
• CLIが実装できない
  • 常時起動ではないためCLIを実装して外部からコマンドを叩くようなことをしたい場合、その処理用のLambdaを新たに立てる必要があった。
• ログの外部出力
  • Datadogにログを出力するためにDatadogが用意したLambdaの拡張機能やライブラリをインストールしました。

今後の展望や取り組み予定について

サービスが伸びたときにサーバーレス以外の選択肢を取ろうと考えていましたが、ある程度サービスが伸びてきたにも関わらず今のところ現状のアーキテクチャで全く問題なく稼働しています。そのため、現状の構成で以下のようなコスト削減やコールドスタート時間削減などを検討しております。また、１AWSアカウントあたり同時起動数1000台までのクォータがあるので引き上げリクエストをするのか違う方法にするのかも今後考えていく予定です。

• コスト削減
  • 現在設定しているProvisioned Concurrencyは固定ですが、プロビジョニング数をApplication Auto Scalingで管理する
• コールドスタート時間削減
  • 非同期化
  • Lambda分割

千株式会社

千株式会社は「みんな、笑顔になぁれ」をスローガンに掲げ、保育業界の課題をITで解決し子どもたちの心と身体を強く育むことを目指す会社です。弊社は複数のサービスを運営していますが、今回はその中でも幼保業界を中心とした写真販売サービスである「はいチーズ！フォト」における通知基盤について説明します。

サーバレスのインフラアーキテクチャについて

「はいチーズ！フォト」の成長に伴い、EC2上で動いている従来のメール通知バッチが抱えていたリアルタイム処理におけるスケーラビリティの限界が顕在化していました。
特に、ユーザー数の増加に比例して通知の抽出から送信までの時間が増大し、パフォーマンスのボトルネックとなっていた点は大きな課題でした。このパフォーマンス問題は、ユーザーへのタイムリーな情報提供を阻害し、サービス体験の低下に直結するリスクがあったため、将来的な通知チャネルの多様化にも対応するべく、通知プロセスのアーキテクチャを全面的にリプレイスしました。

本アーキテクチャにおいては抽出と送信プロセスの完全な分離をすることで各プロセスが独立してスケール可能となり、システム全体の柔軟性と耐障害性が向上しました。
具体的には、以下のアーキテクチャを採用しています。

1. 抽出基盤

   • 通知対象ユーザーのデータ抽出後、その結果をParquetファイルとしてS3に集約する設計としました。Parquetの採用は、カラムナ構造と圧縮効率の高さから、大量データI/Oにおけるパフォーマンス向上を期待してのものです。
   • これにより、後続の送信基盤はデータソースへの直接的な依存なく、S3から高速かつ効率的にデータを読み込むことが可能となっています。

2. 送信基盤

   • S3に格納されたParquetファイルを起点として、各通知チャネルに最適化された送信タスクを並列実行します。
   • LINEの通知側はStepFunctions(Lambda)、ブラウザのPush通知側はECSでそれぞれ送信のタスクを実行することで高速で大量の通知の配信を実現しています。
   • Lambdaはzipではなくコンテナイメージでデプロイする方式を採用しているので、パフォーマンス次第で迅速にECS環境に移行することができるようにしています。

今後の展望や取り組み予定について

現状、LINE通知はAWS Step FunctionsとAWS Lambdaを組み合わせて実装されているため、今後もユーザーが増加し続けると、Lambdaの実行時間上限（15分）に到達するリスクが高まります。
この課題に対処するために、以下のいずれかの方法での改善を計画しています。

1. 対象分割によるLambda実行の最適化

   • 既存のLambdaベースの実装を活かしつつ、通知対象ユーザーをより細かく分割し、それぞれのLambda関数で並行処理することで、個々のLambdaの実行時間を上限内に収めるアプローチです。

2. ECSへの移行

   • ブラウザのPush通知と同様に、Amazon ECS上でLINE通知処理を実行するアプローチです。
   • Lambdaの実行時間制限から解放され、より長時間の処理や、よりリソースを必要とする処理に対応可能となります。

また、新規の通知チャネルへの対応を優先してきたため、現在EC2上で稼働しているメール通知バッチの新しい通知基盤への移行が完了していません。このメール通知バッチも、将来的なスケーラビリティと運用効率の観点から、新たな通知基盤のアーキテクチャに統合することが不可欠なため、今後移行を進めていく予定です。

◆執筆：千株式会社　ものづくり部　高倉 輝

シンプルフォーム株式会社

「全ての法人がフェアに繋がれる世界」をミッションに掲げ、日本の審査を支えるソリューションを展開しています。全国500万法人に関する定性情報の収集とデータベース構築に取り組み、このデータベースを基盤としたプロダクト「SimpleCheck」「SimpleMonitor」を開発・提供しています。

これらプロダクト開発に携わるチームは、プロダクトごとの開発チーム、QA、PdMを中心に構成されています。さらに、これまでにない機能を生み出すR&Dチーム、データ収集の高度化・効率化を実現するデータオペレーションチーム、そしてインフラ・セキュリティチームが連携して業務を推進しています。

サーバレスのインフラアーキテクチャについて

シンプルフォームのサービスはAWS上にサーバレスかつマイクロサービスとして構築しています。
サービスの中核を担うのが、全国500万を超える法人の実体・実態に関わる定性情報をレポートとして提供する「SimpleCheck」です。 法人名を入力するだけで、その時点で取得できる最新のWEB情報と、それまでに収集・蓄積し続けたデータとを組み合わせ、独自の知見に基づくリスク情報と併せて30秒でレポーティングします。

もう一つのメインプロダクトが「SimpleMonitor」です。対象法人を継続的に監視し、リスク評価に関わる重要な情報・属性に変化が生じた際、自動で通知を行います。
これらプロダクトを実現するアーキテクチャの特徴と工夫は以下の通りです。

• リアルタイムであらゆるデータソースから情報を収集し、収集したデータを統合してレポーティングするための、50を超えるLambda関数で構成されたマイクロサービスアーキテクチャ
• 数多くの情報を高速に描画するためのインメモリキャッシュElastiCacheの利用
• 法人名（正式名称）だけでなく、法人名の一部やカナ、法人に関する住所なども含めて全文検索を可能とするOpenSearchの活用
• レポート対象の法人に関連する別の法人との関連性までを提供するため、グラフDBであるNeptuneを活用（※1）
• リアルタイムには収集できないデータを、「面倒を愛する」カルチャーのもとマンパワーとクローラーを組み合わせてデータ収集するためのECSサービス群

プロダクトとは別に以下の技術を利用しています。

• 収集・蓄積したデータを分析し、弊社独自の知見をもとに価値を提供するためのSnowflakeを中心としたデータ基盤（※2）
• プロダクトの信頼性・可用性を維持するためのオブザーバビリティツールであるSentry、New Relic
• GitHubでのコード管理、およびGitHub ActionsによるCI/CD

また、業界・お客様の特性もあり、創業当初からセキュリティに力を入れています。アーキテクチャ図には示していない工夫として、AWSのベストプラクティスに則ったマルチアカウント構成、Security HubやGuardDutyなどのセキュリティサービスを活用して脆弱性や脅威への対応を行っています。

※1) Amazon Neptune を活用したシンプルフォーム社のリスク評価サービス
※2)Amazon Redshift から Snowflake へのデータ基盤移行

今後の展望や取り組み予定について

大きく２点あります。

1. アーキテクチャの適切な統合と分離
   プロダクト初期からマイクロサービスアーキテクチャを採用したため、サービスごとに最適化された構成になっているものの、設計思想が異なる部分があり認知負荷の高さが課題となっています。マイクロサービスアーキテクチャの利点はそのままに、コードレベルで品質・保守性を高めるためのモノリス化を検討しています。
   一方で、新機能や新プロダクトの開発を高速に進めるために、R&D用の基盤をプロダクトから分離し、異なるサービスレベル・セキュリティレベルで開発・運用していく取り組みも進めています。
   

2. インフラリソースの標準化とデプロイの簡素化
   インフラリソースはTerraform/Terragruntにより、環境（production, stagingなど）ごと、リソースごとに管理しています。異なる環境に同じリソース、または一部のパラメータのみ変更したリソースを構築する際に適している一方で、リソースが増えると依存関係が複雑になったり、不要になったゾンビリソースの管理が煩雑になってきました。
   この課題に対し、類似のリソースを抽象化・統合（標準化と呼んでいます）するとともに、複数リソースを1コマンドでデプロイできるようにして、急な環境増設にも対応できるデプロイの簡素化を検討しています。
   

◆執筆：入江 純 / エンジニアリングマネージャー / プラットフォーム
@jirtosterone