システムは分割せず、新しいサービスで置き換えていく
マイクロサービスは、複雑化したシステム（モノリス）の弊害となる機能間調整や実行時影響（スローダウン）を解決するために生まれた。機能間の依存をなくしてしまえば、機能間調整や実行時の影響を抑えることができるという発想だ。技術的には機能をサービスに分割し、APIでつなげる。サーバーもデータベースも独立できるので、スローダウンが起こりにくくなる。
またマイクロサービスは、各モジュールが単一の明確な責任を持つ「高凝集」、各モジュールが独立し依存しない「疎結合」な設計にすることで将来の変更容易性が高まる。各モジュールはアジャイルで開発するのが基本だ。
ただし高凝集・疎結合は実現難易度が高いという課題もある。逆に低凝集・密結合、つまりモノリスの「大きな塊にいろんなものを詰め込める」スタイルにもメリットはある。分割を考えることがないので、設計がシンプルになる。サーバー台数が少ないので全体管理コストも低い。加えてデータの整合性は、データベースのトランザクション機能が保証してくれる。
なお昨年GitHubの元CTO Jason Warner氏が「近年のアーキテクチャにおける大きな間違いは、すべてをマイクロサービス化しようとしたこと」とツイートしていた。鈴木氏も「全く同じ考え」と言う。「粒度を考慮することは大事だし、いきなりすべてをマイクロサービスにする必要はない」
基本的なセオリーはいいとして、実際に既存のシステムをマイクロサービスにしようとすると壁が立ちはだかる。一括再構築ではうまくいかないし、単純な分割も成功しにくい。むしろ密結合のまま分割するのは危険だ。
鈴木氏は「マイクロサービス“化”を意識していくことがとても重要」と強調する。対象システム、組織の規模、成熟度に合わせて段階的にマイクロサービスにしていく。途中経過では粒度が混在することもある。
大事なのは既存システムを分割しないこと。その代わりに、新サービスで機能をすり替えていく。システムのなかに機能A～Cがあったとして、まず機能Aを新規のサービスとして作り、システムの中にある機能Aを使わなくする。同様にすべての機能を新サービスとして切り出せたら、元のシステムは使わないようにする。
マイクロサービス化と同様にプラットフォームの整備も重要だ。DevOpsを実現できるような基盤を整備し、共通化していく。一般的にはパブリッククラウドにPaaSを中心に組み上げていくケースが多い。段階的に行うので、長期的な視野が必要だ。例えばNetflixは2008年からAWSへの移行を開始し、クラウドシフトの完了を宣言したのは2016年1月だ。なお最後に移行したのは顧客管理システムだったそうだ。
「見えない壁」を超える人の心構え
今回何度も出てきた見えない壁とは、鈴木氏によると「ビジネスとIT、組織とIT、経営とITの壁」となる。ITに対して「要件を決める」「意思決定する」「投資する」といった期間を、かつての年単位から1週間単位のように大幅に短縮しなくてはならない。企業のさまざまな要素とITの距離を縮めていく必要がある。うまく折り合いをつけながら、壁を打ち破っていくことが大事だ。
「壁を越える人の心持ちも大事」と鈴木氏は言う。まずは他者をリスペクトすること。それぞれのやり方には背景があり、意味がある。自分と異なるからといって否定するのはよくない。目指す先は一緒だと共有し、オープンに話し合う。自分の立場ややり方を分かち合うことで、両者の間に橋を架けていく姿勢が求められる。うまくいかないことがあっても他人のせいにせず、自らで考えて動いていく。鈴木氏は「ただし妥協しないこと」と話し、最後に「今日お話したことが皆さんの中で何かとつながり、動き出すきっかけになればうれしいです」と述べて講演を締めくくった。
エンタープライズDXへの取り組みを紹介中
Graat（グロース・アーキテクチャ＆チームス）は、アジャイルやマイクロサービスへの取り組みを通じて「IT」と「チーム」の力を引き出し、エンタープライズDXを支援しています。中途採用も行なっていますので、ぜひご覧ください！
