マイクロサービスアーキテクトという役割

最近マイクロサービスアーキテクチャが抱える課題を解決するために色々やろうとしているのでまとめてみました。

マイクロサービスアーキテクチャの採用

今さらマイクロサービスアーキテクチャ自体について自分が説明することもないのだが、 マイクロサービスアーキテクチャの目的の1つは "大人数で開発しても開発効率を落とさないこと" であると思っている。 普通に考えて "巨大なモノリスなシステムを大人数で触る" というアプローチでは限界があるだろう。 今ではモジュラモノリスという選択肢もあるので "上手くやれば" モノリスでもある程度の規模までは頑張れるのかもしれない。

開発効率と疎結合な組織

従来のモノリスなシステムにおける大規模開発では、デプロイや実装など開発におけるあらゆる面でチーム同士のコミュニケーションが発生してしまう。 そのため開発規模が大きくなるほど開発効率が落ちてしまう。 一方でマイクロサービスアーキテクチャでは複数のマイクロサービスがAPI経由でやりとりするという性質上、 各チームのコミュニケーションを疎結合に保つことができるようになる。 当然疎結合というのは結合がないわけではないので、特定のポイントではコミュニケーションが発生することはあるが、モノリスなものに比べると十分 "疎" と言えるだろう。

各チームを疎結合にすると、各チームが他のチームに影響を与えることなく開発を進めることができる可能性が高くなる。 コミュニケーションもチーム内で完結することが多くなる。 各チームはスタートアップのようにスピード感を持って動くことができるようになる。 マイクロサービスアーキテクチャを採用するにあたって、技術的な課題の解決も当然重要であるが、 各チームを疎結合にするという組織的な部分も非常に重要である。

しかし、マイクロサービスアーキテクチャは各マイクロサービスがAPI経由でやりとりするので、 何もせずとも各チームを疎結合にするという部分はある程度保証されるような気はする。 当然開発フローや組織構造にもよるのだが、API経由でやりとりしている状況でコミュニケーションを密結合にする方が難しいのではないか。

開発効率と多様性

マイクロサービスアーキテクチャでは各チームを疎結合にすることが重要ではあるが、 疎結合であるがゆえに各チームの多様性を過度に許容してしまうと、開発効率が下がってしまう可能性がある。 なぜ開発効率が下がるかというと、各チームが自分たちのことだけ考えて開発してしまうからである。

マイクロサービスアーキテクチャは各マイクロサービスがAPI経由でやりとりするが、 各チームはそのAPIをどのように実装するだろう。

あるチームは HTTP を利用した REST かもしれない。 あるチームは gRPC かもしれない。 APIに対する認証はどうなるだろう? データ形式はJSON? Protocol Buffers?

マイクロサービスアーキテクチャでは各チームが最適な技術を利用して開発を進めることができる。 ソフトウェア開発は要件が多様化し、技術的な難易度も高くなってきたので、この点はマイクロサービスアーキテクチャにおけるメリットの1つである。 しかし、一方でマイクロサービスアーキテクチャではマイクロサービス同士の通信によって特定のユースケースを満たすというのが前提になっている。 そのため、各チームが何のルールもなく自由に実装してしまうと通信対象のマイクロサービスごとに通信方法を理解しなければいけない。 その際にAPIを提供するチームと利用するチーム間で無視できないほどのコミュニケーションコストが発生するのであれば、 チーム同士が疎結合になっているとは言えないだろう。

当然APIの実装だけが問題になるわけではない。 例えば各チームが自由にプログラミング言語を選んでしまうと、チーム異動時に配属先で毎回新しい言語をキャッチアップしなければならない。 その他の技術やツールにしても同じことが言えるだろう。 組織における人の流動性というのも開発効率という観点では重要である。 テクノロジースタックが異なると組織内でのノウハウ共有も難しくなる。

何をどこまでルール化するか

ここまで大規模なマイクロサービスによる多様性によって開発効率が下がる問題について書いてきたが、 これを解決するためには "何をどこまでルール化するか" という方針が必要になる。

例えばプログラミング言語を1つに統一するというのはあまり現実的ではない。 MLではPythonを使いたいかもしれないし、分散処理ではJVM系の言語を利用したいかもしれないからである。 しかし、ザックリと "少なくともサーバサイドはKotlinに統一する", "XXX部はGoに統一する" という方針であればある程度現実的であり、 人の移動やノウハウ共有もそれなりに頑張れるはずである。

当然そもそも共通化すること自体現実的ではないものや共通化した結果デメリットが大きくなってしまうものもある。 組織の規模、ビジネスフェーズなどなど、様々な変数によって "何をどこまでルール化するか" の最適解は変わってくるだろう。 "ルールを設けない" という選択肢もあり得る。 ただそれすらも "ルールを設けないというルール" であり、 組織としての開発効率を高めるための根拠自体は存在するべきだと思う。

大規模なマイクロサービスアーキテクチャの難しさ

"何も考えず各チームの多様性を全面的に認めてしまうと開発効率が落ちてしまう" という問題は組織内の人の多様性に依存する部分が大きいと思っている。

極端な例だが、1人で10個のマイクロサービスを開発する場合、その10個は同じような作りになるだろう。 しかし、10人で1人1つずつマイクロサービスを作る場合、その10個は同じ作りにはならないだろう。 組織規模が大きいほどマイクロサービスアーキテクチャにおける多様性は高くなるはずである。 そのため例えば2チームで5つのマイクロサービスを作るような規模だとそこまで問題にならない印象を受ける。

人が増えることによって多様性が高まると、開発効率以外にも影響を与える。 分かりやすいのはセキュリティだろう。 一言でいうと "誰が何をするかが分からない" という状況になる。 悪意のある行動はもちろんだが、操作ミスや実装ミスというものが、毎日どこかで発生するような状況になる。 各マイクロサービスが提供するAPIの認証や社内システムの権限管理などなど、あらゆる部分で最低限のセキュリティレベルが求められる。 マイクロサービスアーキテクチャによって各チームがこれらを独自で実装してしまうと、 チームのレベルによってセキュリティレベルがバラついてしまう。 セキュリティチームなどの横断的な組織がそれらをレビューして回ってもいいが、 手が回らなかったり、レビュー漏れがあったり、問題は色々とあるだろう。 そのため、セキュリティに関わる部分は技術的な仕組みで一元管理するなどといったアプローチが必要になるはずである。 具体的な仕組みとしては Google の Zanzibar, BeyondCorp, BeyondProd みたいなものであったり、 ゼロトラストネットワークという考え方自体が必要になってくるはずである。

多様性の高さにおける開発効率とセキュリティの問題について説明したが、 これはある程度大きな組織におけるマイクロサービスアーキテクチャが直面する問題なのではないだろうか。

マイクロサービスアーキテクト

大規模なマイクロサービスアーキテクチャでは今まで話してきた "開発効率" や "セキュリティ" といった、 人の多様性によって発生する問題を解決しなければならない。 このような課題を解決するにはマイクロサービスアーキテクチャ全体や組織全体をスコープにして物事を考える役割が必要である。 自分はその役割を "マイクロサービスアーキテクト" と表現している。

今自分はDMMでエンジニアとして働いているが、役割としてはマイクロサービスアーキテクトである。 最近自分が Twitter でアプリケーションアーキテクチャよりもマイクロサービスアーキテクチャに関するテクノロジースタックを追っているのはそのせいである。

マイクロサービスアーキテクトという役割についてはデブサミ2020で中井さんが言及していたらしい。 資料が上がっておらず、詳細は分からないので、自分の定義するマイクロサービスアーキテクトとは厳密には異なるかもしれないが、 マイクロサービスアーキテクチャ全体に対してアプローチするという部分は同じなのかなと思っている。

togetter.com

"認証認可 x ゼロトラストネットワーク x DDD x マイクロサービス" を扱うマイクロサービスアーキテクトチーム

ここからは宣伝です。 自分が所属するDMMはそれなりに大きい組織なので、当然マイクロサービスアーキテクチャでの開発が必要になってきます。 そのためDMMのマイクロサービスアーキテクチャ全体に対してアプローチする "マイクロサービスアーキテクトチーム" というチームを立ち上げました。

チームの目的は "認証基盤を中心としたゼロトラストネットワークなマイクロサービスプラットフォームを作ること" です。 開発効率を向上させるためのマイクロサービスプラットフォームとセキュアな環境を提供する認証基盤を構築します。 自分が今まで武器にしてきたアプリケーションアーキテクチャも活かしていくので、雑にDDDって書いてます。 立ち上げたばかりなのでチームメンバーは自分だけです。 なので、サーバサイドエンジニアとSREを募集中です。

マイクロサービスアーキテクチャは大きい組織ほど採用することにメリットのあるアーキテクチャ戦略となりますが、 その規模が大きいほど技術的にも組織的にも難易度が上がります。 なので、DMMというある程度大きい組織のマイクロサービスアーキテクチャをリードすることによって得られる経験は貴重なのではないかと思っています。 "認証認可 x ゼロトラストネットワーク x DDD x マイクロサービス" に興味のある人がいたら、是非以下のBosyuを確認してみてください。

まとめ

長々と書きましたが、自分は最近こんな感じです。