皆様、こんにちは！昨日21日金曜日、日本マイクロソフト在籍時の元上司(2006年－2010年頃)成本正史さんを含む MSDN Architecture Center チームに来社して戴きました。日本マイクロソフトからはパートナー担当 Cloud Solutions Architect の近藤和彦君など元同じチームの人や、弊社担当営業の方も来られてていました。私は別件のテレカンに入っていたのですが、途中から参加したので、サマリー等を写真とともに紹介したいと思います。

下記は、弊社社長、成本さん、Architecture Center チームのお二人、そして私、という記念写真です。

成本さんは、私がマイクロソフト入社3年目で公共営業部門のアーキテクトをしていた頃に、エバンジェリストとして異動を勧めてくれた人で、それ以降、私はデベロッパーマーケティングチームに所属し、テクニカルエバンジェリストとして10年以上在籍しました。また現職の社長とも、彼のチーム在籍2年目に、イベントや案件で知り合っており、その意味では、大変縁が深い人と言えます。いろいろまわりまわって今ここにいるのも、彼のおかげというわけですね。

2010年頃に米国本社に移籍して以来、今年で10年目、日本人エンジニアとしてのサバイバルの秘訣なども、今度来社されたときに弊社社員に語って貰うのも良いかもしれないですね。

セッション内容について

弊社の案件絡みのコンフィデンシャルな内容の質問等も多かったので、そのあたりは触れられませんが、一般論としてもいろいろ説明して戴いたので、そのあたりの内容を写真とともにご紹介したいと思います。

マイクロサービスの4要件

マイクロサービスの4要件についてのお話です。

このあたりは私もいろいろなセミナーや勉強会でのセッション登壇でお話しすることが多いところですが、特にこの4つをコアの要件として説明して戴きました。
- 独立してデプロイできる
- サービスごとに別の言語で実装できる
- 独立したスケールアウトができる
- 独立して故障から修復できる

上の3つは良く語られているところですが、4つ目の“障害についても独立している”というのは、結構重要なことで、当たり前なのですが、あまり書いてある文献がないですので、押さえておいて戴きたいところです。

要は、サービスごとに開発がしたいためにマイクロサービスが生まれたという背景があるわけです。

なお、政府の調達の話でも、デジタル手続法案成立後の現在、本格的にクラウドファーストの方針の下で、調達を進めていくことになっており、私は特に国レベルのマイクロサービス基盤の整備、というところをデータ連携の観点から纏めていくチームに入っています。このあたりはまた別の機会にご紹介できればと思っています。成果物もどんどん出していきます。政府CIOポータル

失敗しがちなパターン

さて次に、失敗しがちなパターンについて、説明して貰いました。

- 下のレイヤーが上のレイヤーに依存する
- 依存関係がわからなくなる
- 変更の影響範囲がわからなくなる
- リポジトリが統一されててサービスごとのデプロイができない

これらはよくやりがちな失敗として挙げられますよね。

最初の設計時に、そもそもこのあたりを意識してやって行かないと、なかなか難しい課題に、途中で直面する、ということになるわけです。特に4つ目の内容は、もはやデータを共有しているわけでサービスとして独立性を維持していない状況になっています。

ASCII Azureboost の連載でも詳細を書く予定ですが(すみません、ちょっと遅れています)、要は分散システムとして、メリット・デメリットを意識して、マイクロサービス基盤の設計をしていかなければならないです。すなわち、エンタープライズにおける分散システムの設計そのものに立ち返って、検討していかないと適切な設計はできないので、そのあたりも注意が必要ですよね。

うまくいく例

- ビジネス要件をモデリングして影響範囲を明確にする
- DBも分離(物理的でなくても別テーブル等の分け方もある)
- ライブラリをNuget等で疎結合に
- 一つのサービスのダウンが他のサービスに影響しない

上手くいく例を上げて戴いています。ただし、例えばモデリング等は、最初からこうできれば問題ないに決まっています。問題はどうやってそこを見極めていくかで、一朝一夕には答えは出ません。

データベースの分離は、これはやっておかないといけないですよね。最低限ここから検討して、永続化できる単位で、取り組んでいきたいところです。

また、Nugetの活用は重要です。同じような仕組みにしたいですね。あとは、障害の分離のところでも書いた通りです。

他の課題と今後の展望

- 複雑すぎになる<->モノリシックならシンプル
- 機能の重複(対策を立てる必要あり)
- データの一貫性
- 統合テストが難しくなる
- 故障が起きたサービスを特定するのが困難になる
- ガバナンスの問題

マイクロサービスには他にもいろいろ課題があります。特長と言われているところの裏腹にあたるのが課題だと思って戴ければ間違いないと思います。やっぱり難しいか難しくないかと言えば、サービスの粒度切り出しにしても、全体の設計としても、難しいとは思います。また向いてないシステムもあります。必要のないシステムも多いです。それを無理やり偉い人の意向や営業的な理由などで、実装してしまうとそこから大変だったりします。

私は、de:code 2019 のCD42セッションでもお話ししました通り、このあたりは、分散システムの基本にもう一度立ち返って考えて戴くと同時に、どこまで投資対効果が見つけられるか、マイクロサービスを採用して今後5年10年進化する個別のサービスとして育てていく必要＆価値があるか、を基本に、採用の可否を検討すべきと思っています。

そして、このあたりについては、de:code 2019 のDT52セッションでも予告しました通り、継続的にオンライン・オフラインで、皆様と一緒にディスカッションの機会が持てたらいいなと思っている次第です。

今後ともよろしくお願いします。