アーキテクチャConference2024 参加レポート

はじめに

こんにちは、梅雨です。

今回はファインディ株式会社さん主催のアーキテクチャConference2024に参加してきたので、そこで得られた知識などの一部をメモとして共有させて頂こうと思います。

ビジネスの成長を加速するB2B Saasのスケーリングアーキテクチャ

スピーカー

• 株式会社アンチパターン 小笹 佑京 さん
• アマゾン ウェブ サービスジャパン合同会社 櫻谷 広人 さん

概要

B2B SaaSにおいては、複数のテナントに対し同時に価値を提供していくことによって、ビジネスとソフトウェアを加速度的にスケールさせることが事業成長の鍵を握ります。そのため、アーキテクティングにおいては、スケールに焦点を当て、「マルチテナント」や「SaaS スプリットプレーンアーキテクチャ」の概念をどう扱うかが重要です。本講演では、インフラアーキテクチャに留まらず、アプリやデータストアの設計に関わる「デプロイメントモデル」を含めたB2B SaaSアーキテクチャの特異性に焦点を当て解説をすることで、B2B SaaSの魅力を発信することを試みます。

講演メモ

B2B SaaSは業務を標準化（Fit to Standard）し、クライアントがソフトウェアに適応するデリバリーモデルが基本となる中、効率的なスケーリングが課題となる。

その中で、顧客に価値を提供するアプリケーションプレーンと全体の制御を行うコントロールプレーンを分離するスプリットプレーンアーキテクチャという概念を導入することで、継続的な機能開発や拡張性を確保することができる。

コントロールプレーンはテナント型のSaasにおいて必ず考え、サービスインの時点から考慮すべきものである。全てのコントロールプレーンを実装できない場合は、オンボーディングなどの重要度の高いものから優先して取り組む。

コントロールプレーン

• オンボーディング
• テナント管理
• ID管理
• 請求
• デプロイ

オンボーディングはE2Eのセットアップ作業全般を指す。各ユーザがサインアップを行うまたはプロバイダが発行するものであり、スケーリングにおいて最も重要な機能である。

ID管理に関しては、ユーザアイデンティティとテナントアイデンティティを複合したSaasアイデンティティを考えて認可・認証を行う必要がある。

これらのコントロールプレーンが実装されていないと、スケーリングの際に大きな負荷となり事業の拡大を阻害してしまう。

AWSのSBT（SaaS Builder Toolkit）は、これらを支えるツール群として提供され、CDKコンストラクトにより迅速な実装が可能である。

アプリケーションプレーン

顧客に直接価値を届ける機能群であり、サイロ、プール、ブリッジといったデプロイメントモデルが存在する。

• サイロモデル: テナントに専用リソースが提供されるアーキテクチャ
• プールモデル: テナントがリソースを共有しているシナリオ
• ブリッジモデル: サイロモデルとプールモデルのシステムを併用

ビジネス要件やテント要件、技術要件などに応じ、サイロ、プール、ブリッジモデルの選択を最適化する。

ノイジーネイバー問題とは特定のテナントによってリソースの圧迫が起こり、別テナントに影響を与えてしまう問題のことを指す。

Mixed Modeデプロイメントモデルとはモデルをマイクロサービスのワークロードごとに選定するモデルであり、これはデプロイメントモデルが事業の成長とともに継続的に変容すべきであることを示している。

3社と語るAWS Architecture レビュー会

スピーカー

• アマゾン ウェブ サービスジャパン合同会社 内海 英一郎 さん
• 株式会社アンチパターン 矢ヶ崎 哲宏 さん
• 弁護士ドットコム株式会社西野 裕貴 さん
• ファインディ株式会社下司 宜治 さん

概要

本セッションでは、Special SponsorであるAWS社の特別企画として、アーキテクチャレビュー会を実施します。アンチパターン社、弁護士ドットコム社、ファインディの3社が自社のドメインに基づいて、どのようなアーキテクチャを構成しているか、AWS チーフテクノロジストの内海さんと深掘ります。

講演メモ

パネルディスカッション形式につき割愛

「ソフトウェア開発の複雑さに立ち向かう」

スピーカー

• 有限会社システム設計 増田 亨 さん

概要

あらゆるところでソフトウェアが使われる時代になり、ソフトウェアを開発する機会が増え続けています。
しかし、時間や予算という制約条件の中で、複雑で高品質なソフトウェアを生み出し発展させていくことは、簡単な仕事ではありません。
ソフトウェア開発にあらかじめ決まった答えはありません。ソフトウェアを開発するために、私たちエンジニアは探索と発見を繰り返します。つまりソフトウェア開発とは継続的で終わりのない学習活動です。
このセッションでは、次の４つの視点から、エンジニアの学びと成長について考えてみます。

• 解決すべき課題を大きな文脈から理解する
• 多数の小さな一歩を効果的に積み重ねる
• 設計原則を深く理解し、目の前の課題解決と関連づける
• 学びの実践共同体に主体的に参加する

講演メモ

かつてのソフトウェア開発では、設計に時間をかけることが一般的であったが、現代においては変動性や不確実性といった予測しづらい状況下で設計を進めていかなければならなくなっている。特に、クラウドの普及に伴い、データ量とその種類が爆発的に増加した。この結果、データを扱うソフトウェア開発は一層複雑化している。

しかし、本当にそれだけがソフトウェアの複雑化の原因なのかどうかは一考の余地がある。技術が進展しているなら、状況は予測しやすくなってもよいはず。それでもなお、ソフトウェア開発が難しい理由は、デジタル化の進行によって、事業活動とソフトウェアシステムが密接に結びつき、一体化している点にある。この変化により、ソフトウェアエンジニアは事業活動の当事者として、事業とシステムを同時に考えなければならなくなった。

予測しづらい状況（VUCA）に対処するためにOODAループを適用することが有効である。

VUCA

• Volatility（変動性）
• Uncertainty（不確実性）
• Complexity（複雑性）
• Ambiguity（曖昧性）

OODA

• Observe（観察）
• Orient（方向付け）
• Decide（意思決定）
• Act（実行）

継続的な観察と学習を通じて柔軟に対応する姿勢が、現代のソフトウェア開発において重要な鍵となる。

事業課題と設計方針を一致させるためには、以下の4つの品質特性を軸として考えることが重要である。

1. 合目的性
   事業課題と設計が整合していること。
   機能要件を満たすことが最適な設計とは限らず、事業の本質に適合した設計が求められる。

2. 経済性
   ソフトウェアが事業に与える経済的な影響。
   売上増加やコスト削減を促進する設計が目指される。

3. 変更容易性
   事業活動の変化に追随できる柔軟性。
   事業の変化に合わせてモジュール化しやすい設計が重要である。

4. 相互運用性
   アプリケーション間のスムーズな連携。
   必要に応じてモデル間の繋ぎ方を工夫し、無駄な分散を避けるべきである。

事業課題に寄り添ったソフトウェア設計を行うための具体的なアプローチをとして以下の4つが考えられる。

1. 予測しづらい状況下の行動モデル
   状況を変化させ、その結果を観察することで経験を積み、設計を進化させる。変化そのものを学習の機会として活用する姿勢が求められる。

2. 競争優位分析とソフトウェア設計
   競争優位性が事業の本質であると捉え、競合他社との差別化と業務ロジックの複雑さを二軸で分析する。

3. 事業視点での関心の分離とモジュール化
   業務ルールに焦点を合わせ、競争優位を強化する設計を実現する。具体的には、対象業務に関心のある値とその計算ロジックをカプセル化し、業務の変化に柔軟に対応できる仕組みを構築する。

4. 事業視点でのアプリケーション間連携
   異なるモデルを接続する際には、その関係性を考慮する。対等な関係と、一方が優位な関係があり、どちらを採用するかが重要である。また、単に分散を増やすことが解決策とは限らない。

ソフトウェア設計は、一度きりのプロセスではなく、継続的な学習行動そのものであり、OODAループを繰り返し、事業課題に最適化された設計を模索していくプロセスこそが、複雑さに立ち向かうための唯一の道である。

大規模データを扱うクラウドセキュリティプラットフォームのアーキテクチャ変遷

スピーカー

• 株式会社Cloudbase 宮川 竜太朗 さん

概要

CloudbaseではAWSやGoogle CloudといったIaaS, PaaSのセキュリティ診断プラットフォームを提供しております。内部的にはクラウド上の構成データやパッケージデータを取得してきてセキュリティ診断を行なっています。多種多様なサービス、OSなどをスキャンするため、品質の担保の課題や複数チームでの分業体制など考えることが多岐に渡ります。これらの課題を解決するために、アーキテクチャやチーム構造で試行錯誤を繰り返してきました。この発表では試行錯誤の歴史についてお話しします。当セッションはクラウドセキュリティの知見がなくてもご理解いただける内容となっております。

講演メモ

クラウドセキュリティの取り組みは、資産管理、設定ミスの防止、OSS脆弱性の対応など多岐にわたる。CloudbaseではScanner Guild と Web Guild の2つの基盤に分けたアプローチを採用している。

Scanner Guild

• 非同期ジョブの実行基盤として、取得データからセキュリティリスクを検出
• AWS、Azure、GCPなどのマルチクラウド環境がGoで実装されている

Web Guild

• SaasのUI提供基盤
• TypeScriptで実装されている

対応するクラウドの拡充によりモジュール増加が発生する特性をもつため、信頼性の高いパイプラインの構築と書き込みのスパイクに耐えるスケーラビリティが重要である。

アーキテクチャの変遷

4人時代にシステムの原型が整備された。システム特性の差異によってWebとScannerの分離が明確化。TypeScriptでフロントエンドとバックエンドを統一し、RLSを考慮してPostgreSQLを採用。実行基盤には監視の観点からAWS Step Functionsを採用した。開発者全員がシステム全体を把握し、レビューも全員で実施。

8人時代にはCTOがすべての状況を把握することが困難になった。また、ドメイン知識が増え認知負荷が増大した。各コンポーネントのオーナーシップが不明瞭である問題を解消するためにWebチームとScannerチームを編成し、それぞれにPMを配置。横断的にPdMの存在を導入。

15人時代ではScanner Guild内での認知負荷がさらに増加した。またチーム間での検証・仮説立案の機会が増加したため、Guildを横断するTeam Topologiesの考え方を導入。
コンウェイの法則に従わず、各Guildで標準化を実施した。

これからは、全てのワークフローの一元管理からキューを用いた非同期アーキテクチャを目指す。

Web Guildはフロントエンドとバックエンドの型を共有化、QAポリシーを策定による品質向上を目指しており、モジュールのモノリス化やマイクロサービス化は検討していない。

Scanner Guildでは開発キットを整備し、モジュール化を促進していく。またWeb Guild同様にQAポリシーを策定していく。

もし8人時代にStream Aligned Team（特定コンポーネントの責任を一貫して負うチーム）を導入していた場合、コンポーネントごとの責任範囲が早期に明確化されていた可能性がある。また、Stream Aligned Team がプロダクトスケールに応じて迅速に拡大していた可能性が考えられる。

選んだ道を正解にするには、学習と適応が欠かせない。組織やアーキテクチャもプロダクトと同じように、アジャイルな進化を遂げるべきであり、この柔軟性をによってクラウドセキュリティの複雑さに立ち向かう体制を強化できる。

マルチプロダクト戦略におけるデータ分析プロダクトのアーキテクチャ

スピーカー

• 株式会社Hacobu 三木 拓史 さん

概要

Hacobu が開発した共同輸配送支援サービス「MOVO X-Data」のシステムアーキテクチャについて紹介します。MOVO X-Data は月間17億レコードを処理する動体管理サービス「MOVO Fleet」のデータを分析するためのシステムで、MOVO シリーズの他プロダクトを含めた複数システムを横断して分析することが計画されています。物流ビッグデータを処理する基盤やプロダクトを跨いでデータ分析を行うための仕組みについてお話しします。

講演メモ

株式会社HACOBUは「運ぶ」という物流プロセスの最適化を目指し、アナログなやり取りや非効率な意思決定による課題をデータ活用で解決している。この取り組みは、企業間連携の不足を補い、蓄積されたデータを活用して輸配送の合理化を実現するものである。

HACOBUでは、ジオフェンスや車両トラッキングを活用し、月間17億レコードと膨大なデータを処理している。

位置情報の処理基盤

デバイスが5秒ごとに位置情報をアップロードし、1日あたり約2000万リクエストが発生する。AWS Lambda を利用して処理を非同期化。障害発生時にそなえて Kinesis を利用してデータを一時保存し、データロストを回避。
位置情報はDynamoDBに保存し、プライマリキーを車両ID、ソートキーを時刻とする構成で効率的なクエリ処理を実現している。

ジオフェンス処理基盤

ジオフェンスを基準に、車両が特定エリアに進入または退出したかを判定。基準時間を超過した場合に実績データを生成する。
車両IDをキーにしてデータを Kinesisシャード へ分配。シャードごとに Lambda関数 が1つだけ割り当てられており、同一車両の処理を担当する構成になっている。
マイクロバッチで監視、処理を行うことにより、アップロードイベントがなくても進入判定の実施が可能になっている。

データ分析基盤

運送会社ごとの稼働時間や運行パターンの違いを考慮し、物流の効率化を図る必要がある。
複数の運行データをグルーピングし「コース」を定義し、
午前中稼働のコースと午後稼働のコースを1台で効率的に運用できるかを時間的・空間的に検討。
物流の競合がない領域においてデータ共有のルールを作成し、運送会社間の協力を推進。
Athena を活用し、膨大なデータを1000件単位で効率的に処理。全データをメモリに載せる必要を排除し、リソース負荷を軽減している。

ストリートファイター6のアーキテクチャが決まるまで

スピーカー

• 株式会社カプコン 井上 真一 さん

概要

要件定義や判断基準などゲームならではの部分をご紹介したうえで、アーキテクチャ確定に至るプロセスについて最新事例をもとに解説します。

講演メモ

開発に携わるエンジニアは、以下のように役割分担されている。

• アプリケーションエンジニア：ゲームロジックやUIの実装
• ネットワークエンジニア：内製のゲームエンジンである「RE ENGINE」の改良や性能向上
• ソリューションエンジニア：データ分析や基盤技術の支援

2024/06/02にリリースされたストリートファイター6はただのシリーズ続編にとどまらず、一般ユーザーにも楽しめる体験を提供することがテーマとなっている。ゲームは3つの主要モードで構成されている。

• ファイティンググラウンド

従来のコマンド入力の難しさを緩和する「モダン操作」を採用。初心者でも簡単に操作を楽しめる設計。

• ワールドツアー

シナリオモードで、ゲームの世界観を体験。
チュートリアルとして機能し、新規プレイヤーを引き込む仕掛け。

• バトルハブ

仮想ゲームセンターで、カジュアルな対戦や交流を促進。
新しい形のオンラインコミュニティを構築。

対戦型ゲームにおいて、オンライン対戦の品質は非常に重要であり、特に60FPSでの完全同期を実現するための設計は非常に難しいものである。これにはクライアント側でズレを揃えるような処理が必要不可欠である。

アーキテクチャ構成

世界中でのユーザー分布を考慮し、GCPを採用。
Kubernetesでのコンテナ化と、BigQueryを用いた分析基盤を構築。
Spanner をUSリージョンに配置し、他リージョンへの内部回線でのデータ振り分けを採用。これにより、高速なデータ処理を実現。
加えて、かつてはタイトルごとに実装されていたシステムをマイクロサービス化することで汎用性を向上。サービス間通信には gRPC を利用。

GCPの採用は、Spannerの性能を最大限に活かすことを重視した結果である。

「ストリートファイター6」の収益は、おもしろさの追求という目標に再投資される。エンジニアリングやデザインの進化を通じて、ユーザー体験のさらなる向上を目指している。

おわりに

今回のConferenceでは上記の企業以外にもさまざまなスポンサー企業のアーキテクチャが紹介されており、非常に為になる知識を多く得ることができました。

来年の開催も既に決定しているので、興味を持った方はぜひ情報をチェックしてみてください。