GMO Developers Day 2022｜越境のデザイン–ソフトウェアからのアプローチ / 開発者向けブログ・イベント

GMOインターネットグループは、事業の成長を加速させるため、マイクロサービス化の道を選択しました。しかし、そこにはさまざまな困難が待ち受けています。ただ漫然とシステムを切り刻んだだけでは、思い描いた未来にはたどり着けません。

GMOインターネットグループ株式会社成瀬允宣は、12月6日（火）～7日（水）に渋谷フクラスおよびオンラインにて開催されたテックカンファレンス「GMO Developers Day 2022」のスピーカーセッションで、開発者がその力を最大限発揮できる環境を目指してソフトウェア設計面から取っているアプローチについて紹介しました。

登壇者

成瀬允宣　
GMOインターネットグループ株式会社
テックリード／デベロッパーエバンジェリスト

開発生産性向上を目指し、マイクロサービス化を決断

事業が成長し、システムが肥大化すればするほど開発生産性は落ちていきます。マイクロサービス化を決断した背景には、開発生産性を150%アップしたいという目標がありました。

生産性向上にあたって課題となっていたのは、まず共通データベースの存在です。データベースを複数のサービスで共有していたため、システムの拡大につれて深刻な依存関係が生じていました。また、複雑怪奇なシステムにより一子相伝になりやすいのも課題で、成瀬によると「当時、自分が所属していたチームのバックエンドチームでも、一人前になるまでに3年掛かるという話をしていた」ほどだったといいます。さらに、各システムで機能が重複しているうえに、それぞれに微妙な違いが生まれているような状況で、統制がとれていないという課題もありました。

マイクロサービス化への道筋は、ソフトウェアから「越境」をデザインすること

システムアーキテクチャを考えるにあたっては「システムを設計する組織は、自らのコミュニケーション構造を真似た設計を生み出すよう制約される」というコンウェイの法則が知られています。たとえば、アプリ開発チームとインフラチームのあいだに壁があると、チームごとに個別の設計を反映してしまう弊害が出てきやすくなります。マイクロサービス化にあたっては、この法則を逆手に取り、チームと組織構造を進化させて望ましいアーキテクチャへと導く「逆コンウェイの戦略」が有効となります。

ただし、これはあくまで前提であり、チームを単に分割しただけでは、リファクタリングのための作業時間が捻出できない上に、主導者が不在となり調査・改修のためにチーム横断のコミュニケーションが発生するなど、円滑に開発を進めていくことが困難となってしまいます。そこで、こうした課題を運用でカバーするのではなくエンジニアリングで解決するという方針を取ることにしました。

ソフトウェア開発の現場にある不必要な壁を取り払うことでイメージされやすいのがDevOpsではないでしょうか。しかしマイクロサービス化においてDevOpsのように開発と運用チームを安易に越境させてしまうと、共通データベース問題が起きてしまいます。マイクロサービスアーキテクチャを選んでいながらもサービスが密結合している分散モノリス状態となり「モノリスのデメリットとマイクロサービスのデメリットを併せ持つ最悪のパターンになってしまう」（成瀬）ため注意が必要です。

「“水の低きに就く如し”という言葉があるように、人は楽な方に流れてしまうので、安易な越境を防ぐためには、望ましいやり方が最も安易であるようにすることが求められる」と成瀬。講演タイトルにある「越境のデザイン」とは、これをソフトウェアからアプローチしようという発想に基づいているといいます。

サービス/チーム境界を越境するAPI

モノリスで構築している段階では共有データベースは有利となりますが、データベースを共有するとデータストアを経由してサービスを超えた依存関係が生まれてしまうため、中長期的には不利になります。この対策として一般的にはAPIの利用が有効とされています。GMOインターネットグループでは、チーム間の連携のほとんどにHTTP APIを利用していました。ただ、チーム内ではさまざまなデータベースを共有している状況にあるため、複雑な依存関係がありました。そこで、HTTPによるコマンド受付を行いメッセージブローカーを使うようにすることで共有データベースを廃止することを目指しました。

メッセージブローカーを利用することのメリットは、耐障害性の高さです。サービス同士をRPCでつないでしまうと、あるサービスが落ちたときにそれを呼び出しているサービスも落ちるという形で、他のサービスにまで影響が及んでしまいます。一方、メッセージブローカーを用いた場合、障害発生時にメッセージブローカーが稼働していれば、そこにメッセージを貯めて復旧した際にメッセージを消費する流れになり、他サービスへの影響を防ぐことができます。

システムにおける過去・現在・未来の時間軸を越境するイベントソーシング

次に問題となるのは、どのようなメッセージを送るかということです。メッセージは、指示を表す「コマンド」と「クエリ」、そこで起きた事象を表す「イベント」の3種に分けられます。そして、イベントを送る際にポイントとなるのが、イベントソーシングです。イベントソーシングとは、データの現在の状態を格納する代わりに、実行されたアクションを記録するというGitのような考え方です。

イベントは、イベントジャーナルに保存され、Relayでメッセージブローカーに渡されます。これが実現できると、開発面で大きなメリットがあります。既存サービスの情報をもとに新しいサービスを作りたい場合、過去のデータであればすべての履歴がイベントジャーナルに保存されているので、既存サービスを修正しなくてもよい可能性が高まります。また、予測不可能な未来への対策を行うこともできるようになります。

組織上のメリットもあります。多数のサービスが使っているサービスの担当チームに修正・機能追加の要望が集まると、チームが疲弊しリードタイムの低下につながるおそれがありますが、メッセージブローカーにイベントが送出されていれば、他のチームが「勝手に使っている」状況が生まれ、他サービスのための作業を減らすことができるようになります。

個人間・チーム間の知識を越境するイベントストーミング

メンバーが退職してしまうと、開発力が低下するだけでなく、ドメイン知識などソフトウェア化対象の周辺知識や属人化した知識が継承されないという問題が発生しがちです。

こうした知識を共有する方法として、コードのコメントがありますが、システム横断の知識が記述できないほか、記述箇所を探すのが難しかったり、メンテナンスされなかったりという課題があります。ドキュメントを作成する方法もありますが、ビジネス最前線では仕様が変化しやすく、メンテナンスの難しさが難点となります。

そこで有効となる手法が、イベントストーミングです。イベントストーミングは、ワークショップ形式のモデリング手法であり、ブレインストーミングのイベント版のようなものといえます。参加者はイベントを思いつく限り付箋へ記入し時系列に並べ、ルールに従って必要な付箋を追加していきます。そして、出揃ったものに対してチームで納得のいく命名をして、コンテキストで分割していきます。コードを用いないため開発職ではない人も参加できることが特徴で、成瀬は「仕様に詳しいビジネス職の人を招いてワークショップを行うと知識がマージされていく」とそのメリットを語ります。

イベントストーミングを行うと、個人の知識がチームの知識として昇華されていくため、メンバーの退職に慌てないで済むほか、新しいメンバーも知識をキャッチアップしやすくなります。さらに、サービス同士の連携箇所が可視化されるので、改修時の影響範囲も明確になります。

成瀬は「イベントソーシングとイベントストーミングの相性は最高」だといいます。イベントソーシングを採用していると、イベントストーミングによって作成された図に従ってそのままコードに落とし込むことができるためです。

サービス運営負荷と責任を越境するコンシューマ駆動契約テスト

システムは有益であればあるほどさまざまなサービスに使われるため、何か障害が起こった際には各方面から一手に苦情を受けることになります。さらに、こうしてサービスの供給者（プロバイダ）に責任を持たせてしまうと、依存関係の調査・タスクなどに掛かるコストが増大し、リードタイムの低下につながるおそれがあります。

成瀬によると、コンシューマ駆動契約テストでこうした課題を解決できるといいます。コンシューマ駆動契約テストは、「皆が使っているのなら皆でメンテナンスしよう」という考え方に基づき、サービスの利用者（コンシューマ）がプロバイダに向けてテストを提供するという手法です。

役割・チーム間を越境する組織設計

マイクロサービス化に向けたこうした知見があったとしても、実際のところ開発チームは多忙であり、新たなスキルを獲得するような時間がないという樵のジレンマに陥るケースは多くあります。成瀬も「兼務の技術研究チームで試したところ、本業を優先するために進まなかった。チーム対象にワークショップを実施してみたが、これを継続しようとすると自分と同じ役割の人が何人も必要になる」と苦戦したことを明かします。

ここで必要になるのがチームトポロジーという考え方です。チームトポロジーでは、「ストリームアラインドチーム」「イネイブリングチーム」「プラットフォームチーム」「コンプリケイテッドサブシステムチーム」という4つの基本的なタイプにチームを整理します。そのうえで、各チームは「コラボレーション」（チームとチームが密接に協力して作業すること）、「X as a Service」（最小限のコラボレーションで利用または提供すること）、「ファシリテーション」（障害を取り除くために他チームを支援したりされたりすること）という3つのインタラクションモードを活用します。

これを成瀬が以前行っていた業務に照らし合わせると、下記のように分けられるといいます。

サービス開発 → ストリームアラインドチーム
マイクロサービス化の支援 → イネイブリングチーム
クラウド等の利用方法策定 → プラットフォームチーム
チーム横断のモジュール開発やアーキテクチャ策定 → コンプリケイテッドサブシステムチーム

こうしてチームの役割を整理し、チーム同士がどのように関わるかを宣言してインタラクションモードを使い分けることによって、チーム間の諍いを減らすことができるようになります。

GMOインターネットグループは、まさにこの取り組みを進めているところです。成瀬は、「マイクロサービス化をさせるにはファシリテーションを行えるメンバーの増強が不可欠。チームトポロジーの考え方で状況を整理してイネイブリングタイプのチーム組成を上申したところ、上長の後押しもあって実現できた。これにより、組織的なマイクロサービスを推進でき、各チーム内にも手練れが増えてきた」と現状について紹介。そして「ソフトウェア設計は人の心の動きを考えることから始まる。“水の低きに就く如し”を念頭に置いて、越境をデザインしていくことが大切。GMOインターネットグループも、まだ道半ばだが上手くいくようになってきている」と語り、講演を締めくくりました。