AWS Startup ブログ

AWS で最適なインフラを構築するために必要な要素とは。アーキテクチャ Conference 2024「3 社と語る AWS Architecture レビュー会」

2024 年 11 月 26 日、ファインディ株式会社が主催する「アーキテクチャ Conference 2024」が開催されました。本イベントは、各社のアーキテクチャ構築事例や考え方を共有し、エンジニアの知見を深めることを目的としています。

今回は「3 社と語る AWS Architecture レビュー会」のセッションをレポートします。このセッションでは、株式会社アンチパターン弁護士ドットコム株式会社ファインディ株式会社の 3 社が自社のアーキテクチャや課題について解説。そして、アマゾン ウェブ サービス ジャパン合同会社のチーフテクノロジストがリアルタイムで改善点をアドバイスしました。

<登壇者>

株式会社アンチパターン 取締役 CTO 兼 COO 矢ヶ崎 哲宏 氏

弁護士ドットコム株式会社 AI システムアーキテクト 西野 裕貴 氏

ファインディ株式会社 SRE チームリーダー 下司 宜治 氏

アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 チーフテクノロジスト 内海 英一郎

株式会社アンチパターン

株式会社アンチパターン 取締役 CTO 兼 COO 矢ヶ崎 哲宏 氏

アンチパターン社は、BtoB SaaS の開発・運用・販売を支援する SaaS「SaaSus Platform」を提供しています。このプラットフォームは、テナント管理、認証認可、請求、料金プランといったマルチテナント SaaS に共通する機能を提供することで、サービス事業者が自社固有の機能開発に専念できるようにします。

セキュリティやコンプライアンスに対応するため、「SaaSus Platform」のテナント情報は AWS アカウント単位で分離されています。本セッションでは、AWS アカウント発行から各企業用のインフラ環境が構築されるまでの処理を担うアーキテクチャについて解説しました。

顧客が「SaaSus Platform」にサインアップすると、AWS Control Tower によって AWS アカウントが作成されます。そして、AWS CloudFormation StackSets による初期設定を経た後に、AWS CDK を用いて各種インフラをプロビジョニングします。

これら一連の処理は Pre-vending(事前処理)、Post-vending(事後処理)、CDK-exec(CDK 実行)という 3 層構造で構成されています。そして、特定の層の処理が完了すると Amazon SNS を介して通知が送信され、Amazon SQS で次の層の処理を進めるためのメッセージがキューに蓄積されます。万が一、実行が失敗した場合でも、再実行可能な設計になっているのです。

ここからは、3 層構造の処理についてそれぞれ解説します。顧客の操作によって「SaaSus Platform」のテナント作成がトリガーされると、Pre-vending の処理が始まります。AWS Service Catalog を通じて新しい AWS アカウントを作成し、AWS CloudFormation StackSets を用いて、後続の処理に必要な IAM ロールやリソースを構築します。

Post-vending では、作成されたテナント用 AWS アカウント内の IAM ロールに AssumeRole 操作を実行。その後、テナントアカウントの IAM ロールに External ID を設定し、Core アカウントの Amazon DynamoDB に初期マスターデータを登録します。CDK-exec では、Core アカウントの Amazon DynamoDB に保存された情報を基に cdk.json を生成し、AWS CodeBuild 上で AWS CDK を実行します。

Pre-vending、Post-vending、CDK-exec の処理が完了するまでに時間がかかることが、アンチパターン社の抱えている課題だといいます。その課題に対して、内海は「ロングランニングプロセスを高速化するにはいくつかのセオリーがあります」と説明。「プロビジョニングのステップを可能な限り並列化・並行化する」「プロビジョニングを事前に準備しておく」などの観点からアーキテクチャ改善のアドバイスを行いました。

弁護士ドットコム株式会社

弁護士ドットコム株式会社 AI システムアーキテクト 西野 裕貴 氏

弁護士ドットコム社は、自社に寄せられた 140 万件以上の法律相談や法令、判例、法律書籍など、法律に関する膨大な情報をネットワークとして整理したデータベース「Legal Graph」を構築しています。この「Legal Graph」に生成 AI を組み込んだコアテクノロジーが「リーガルブレイン」です。2024 年 8 月には「リーガルブレイン」を搭載した統合型 AI リーガルリサーチツールを発表しました。

現在、正式リリースのための開発が進行中であり、本番対応に向けた準備を進めています。今後のインフラ構築においては「システムの監視や自動復旧の仕組みなどを充実させつつ、運用負荷を減らすことが重要になる」といいます。

本セッションでは、「Legal Graph」のデータベースを作成するためのデータ分析・加工パイプラインについて解説しました。このパイプラインは、書籍や Web 記事などの PDF ファイルやテキストファイル、判例や法令などの構造化データが入力値です。それらのデータを分析・加工した後、チャンクに分解されたテキストやベクトル検索可能なデータ、コンテンツ間の関係性・関連性を表すグラフデータが RAG データベースとして蓄積されます。

パイプラインの処理は「インデクシングパイプラインの分析・加工」「インデクシングパイプラインの投入」「グラフ構築パイプラインの分析・加工」「グラフ構築パイプラインの投入」というステージに分かれており、これらのワークフローを AWS Step Functions で管理しています。

インデクシングパイプラインの分析・加工ステージの処理は、マネージドサービスを利用せずに AWS Batch にて自前で実装しています。プロダクトにおけるコアの機能であるため、自前で実装することでより精度の高いシステムを実現するためです。その次のインデクシングパイプラインの投入ステージでは、生成したデータをもとに Amazon OpenSearch Service 上にインデックスを作成します。

そして、グラフ構築パイプラインの分析・加工ステージも AWS Batch で実装しています。コンテンツ同士の関連性分析を行い、それを Amazon Neptune にロードできる形式で出力します。処理後の生成データは Amazon S3 に保存。最後に、グラフ構築パイプラインの投入ステージの処理では、Amazon Neptune DB を新規作成して生成データをロードします。

内海は開発スピードを上げるための改善案として「なるべく自分たちでインフラを管理しなくて済むように、マネージドサービスやサーバーレス系のサービスを選ぶこと」「インフラ構築作業をコード化して手作業を回避すること」などをアドバイス。そして、運用負荷の軽減のために、正常系のワークフローと障害対応のためのワークフローの両方を AWS Step Functions で管理することを勧めました。

ファインディ株式会社

ファインディ株式会社 SRE チームリーダー 下司 宜治 氏

ファインディ社が提供する「Findy Team+」は、組織の開発生産性を見える化するサービスです。GitHub や Jira といった各種ツールのアクティビティを自動で集計・可視化し、開発組織・チーム・個人の課題を簡単に特定できます。本セッションでは、「Findy Team+」が多種多様な連携先からデータを取得するための連携バッチについて解説しました。

この連携バッチは、連携先のアクティビティ情報を日次で取得して、表示用にフォーマットしたデータを生成します。バッチの非機能要件として、クライアント・連携先ツールの種類・データの増加に対しても性能を維持することや、セキュリティ確保のためにクライアントごとに処理を分離することが求められます。

さらに、前日分のデータを閲覧可能にするため、日付が変わってからバッチ処理を開始し、クライアントの始業時間までに終了する必要があります。クライアントごとにタイムゾーン(バッチの起動タイミング)が異なるという特徴もあります。

連携バッチのスケジュール管理は Sidekiq で行っており、ワークフロー制御のために AWS Step Functions が用いられています。また、ETL のために Amazon ECS タスクが起動して、さまざまな連携先と接続しています。

Amazon ECS タスクでは、大きく分けて dispatch・import・transform という 3 種類の処理が動作しています。dispatch ではタイムゾーンごとのクライアント一覧を取得して、クライアント単位のスレッドを起動。import では連携先ツールと接続してアクティビティデータなどを取得し、ローデータを格納します。transform ではローデータを表示用に加工して、フォーマットされたデータとして格納。ローデータとフォーマットされたデータはすべて Amazon Aurora MySQL に保存されています。

内海は「スケーラビリティのボトルネックを特定するには、アーキテクチャを複数の構成要素に分解して、データが増加した場合にそれぞれの要素がどのような振る舞いをするかを予測することが重要」と説明。そして、スケールアップとスケールアウトのいずれかを選択する際、基本的にはスケーラビリティが高いスケールアウトを選択して、スケールアウトできないものはスケールアップを選択するべきであると解説しました。

dispatch・import・transform それぞれの改善案を説明した後、即効性の高い方法として Sidekiq の箇所を Amazon EventBridge に変える案を提示しました。Amazon EventBridge はサーバーレスでフルマネージドなサービスであり、負荷に応じたスケールを自動的に行ってくれます。

アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 チーフテクノロジスト 内海 英一郎

内海はセッションの最後に「視聴者のみなさまには、このセッションを通じて実践的なノウハウを持ち帰っていただけたのではないでしょうか。優れたアーキテクチャは、必ず各プロダクトの固有のコンテクストに最適化されています。コンテクストを理解して設計を行うことで、より良いアーキテクチャを見つけることが可能になるはずです」と結びました。