事業会社におけるマイクロサービス化について

がちがちのエンタープライズ系で既存システムのマイクロサービス化に取り組むときに注意したいこと。

儲かる機能をマイクロサービス化する

マイクロサービスの最大の目標は「サービス化された機能のリリースサイクルを、その機能を管理するチームが独自に決定できるようにする」ことです。つまり、システム内の他の機能や他システムとの調整をしないで、いつでも好きなようにリリース可能であることが大事です。もちろん、日中に。

それは何のためかというと「機能をどんどん改善して儲けたい」からです。これまでは、儲かる機能を改善をしようとしても、その他の機能や他システムとの調整や影響範囲調査やリグレッションテストに時間がかかってリリーススピードをあげることができませんでした。この問題が解決できればウハウハできるはずです。

マイクロサービスのサービス分割点について聞かれることが多いですが、それは「ビジネス部門が『早くリリースできたら儲かる』って言っている部分で切ればいい」です。マイクロサービス化によって儲かる度合いが増える、というのが大事です。で、それをビジネス部門と合意する。

とはいえ、そんな自由に切れないわけで、エンジニアはビジネス部門がやりたいことを理解しつつ、良い感じの分割方法や制約条件を整理します。もちろん、できないこともあるでしょう。ただ、それは「基幹システム側の都合に引きずられるからであって、このシステムのせいではない」ことを説明しましょう。そっちに言ってくれ、と。それ以外にも疎結合化（非同期化）は、かならずシステム間で不整合を生み出す可能性を持っています。ビジネス部門に制約を提示し「儲かるから、その制約は飲むよ」と言ってもらうことが大事です。ここでビジネス部門をちゃんと巻き込みましょう。

意思決定システムや運用ルールを変えていく

「機能を改善して儲ける」というのは「儲かる機能を考える」「その機能を作る」「その変更を含んだリリースをする」という一連の流れを前提としています。つまり「作る速度を上げる」という話では、まったく足らないということです。

そこで問題になるのが「儲かる機能を考える」や「その変更を含んだリリースをする」といった部分のプロセスです。

「儲かる機能を考える」の代表的なプロセスは稟議であり「事業部門が儲かる機能を企画して、見積をとって、稟議書を書いて、多層的にROIをチェックされ、なんか指摘に対応し、開発ベンダーを計画書を書かせ、それを精査して、契約を取り交わす」ということをになっています。普通に1ヶ月かかったりします。遅い、遅すぎる。

「その変更を含んだリリースをする」の代表的なプロセスやISMSなどに従った運用プロセスであり「変更を説明する資料を作り、それが安全な変更であることを証明する資料を作り、いろいろなテスト結果を説明し、リリース要員を手配してスケジュールを確定し、多層的に承認を取って、リリース資産を作成して登録し、それをしずしずと本番環境に転送し、サーバ停止しますと掲示を出して、本番環境を1つ止めちゃアップデートし、全部ができたらテストをして、問題なかったら掲示を外してアクセスを許可する」ということになっています。普通に1ヶ月かかったりします。遅い、遅すぎる。

いずれも現在のルールをすぐに変えることはできないでしょう。でも、なんとかしないとスピードが上がらないことも事実です。なんとかするように企画部門と運用部門にも頭をひねってもらう必要があります。

追記：ルールを変えられないなら「リリース内容も決まっていないけど3ヶ月先のリリース日を先に決めて、締め切り駆動でプロセスを進める」というのが推奨になります。

エンジニアをチームでおさえる

良いエンジニアをチームでおさえましょう。少なくとも1年間はチームを維持することを前提にすべきです。チームのサイズは4-8名程度が良いでしょう。ざっくり単価100万だとするなら、年間で5000万円～1億円ぐらいは払うつもりがあるべきです。もちろん、1つのサービスだけで維持できないこともあるでしょうから、その場合は複数のサービスを管理してもらってもよいです。

なお、エンジニアを外部調達に頼る場合には準委任問題が出てきます。出てきますが、なんとかするしかありません。会社同士の関係が良好であれば請負契約（＋変更管理）でも対応できます。内製化もよい判断でしょう。ただ、経験者は必要です。最初は外部メンバーに入ってもらい、段階的に内製化を促進していきます。

分割に備えてプラットフォームを整備する

実際にサービス側のチームとは別にプラットフォーム側のチームが必要になります。システムを分割していこうとする場合、多くのサービスは同じような課題にぶつかります。そういったものはプラットフォームとして提供（あるいは外部のPaaSを採用）することになります。代表的なのはSSOとログです。

1つのシステムだったものを2つに割る場合、それらの2つの間で認証情報を共有する仕組みが必要になります。OAuthのように認証画面から丸投げできる機能を構築してもいいですが、そこまで不要であれば認証情報をキャッシュする先を用意するだけでもよいでしょう。

2つに割れると、統合的にログ分析したくなります。そこでログエージェントをいれて、ローカルの吐かれているログを集約して検索可能にする仕組みがあると便利です。サービス間でAPI連携するならトランザクションIDを発行してログに載せるのも有効です。

プラットフォームを整備するチームは個別のサービス管理するチームとは別に用意しましょう。目的が異なるため、同一にするとサービス管理チーム側にオーバーヘッドがかかり、本来の生産性が測りにくくなるからです。

僕はプラットフォームまで含めた全体配置を考えるのを「大きなアーキテクチャ」と呼び、個別のサービス内の構造や構成を考えるのを「小さなアーキテクチャ」と呼びます。大きなアーキテクチャはプラットフォームチームの管轄であり、小さなアーキテクチャはサービス管理チームの主管です。標準化すべきはプラットフォームへのアクセスインターフェースだけにすべきで、各サービスのフレームワークではありません（プラットフォームを利用するためのクライアントライブラリとかはいいです）。

Agile、Cloud、DevOps、Microservices

マイクロサービスというのは「アジャイルを機能させるための技術的な基盤」であると言えます。2001年のアジャイルソフトウェア開発宣言から、我々はITサービスの提供サイクルを最適化しようと努力をしてきました。2006年のクラウドの登場により、インフラ構成やミドルウェア構成をコード化できるようになり、DevOpsムーブメントは運用機能を自動化し、コードによってオペレーターを不要にしていくようにしていました。結果として、管理ノードの増加に耐えられるようになりMicroservices的な仕組みが実現できるようになったのです。

マイクロサービス化というのはアジャイルソフトウェア開発宣言からの16年間を一気に学ぶ、ということです。いろんなものをすっとばして「サービス分割すりゃいいんでしょ」じゃないんです。マネジメント論と、それを実現するアーキテクチャ論であることをきちんと理解しておくべきでしょう。

明日から取り組め。できないなら、一生できない

マイクロサービス化は明日から取り組めます。ウォーターフォール型で「次回の再構築はマイクロサービスで」ではありません。そんなの絶対にうまくいきません。ちょっとづつ取り組みましょう。

取組みの開始はシステム分析でもビジネス部門の啓蒙でも経営層の説得でもいいです（大抵の場合は経営層から下りてきている話でしょうが）。結局、上記に書いたような様々な変更を行う際に障害になるものを取り除かなくはなりません。その障害を「再構築のタイミングで全部変える」というのはムリです。絶対にムリ。結局、既存のしがらみから抜け出せず、中途半端な理想論と技術論の結果、意味もなくサービスが分割されて、制約ばかりが増えて再構築自体が意味が無かったことになります。

最初に書いたとおり、まずは「儲かる機能を見つけて、分離する」ということをしましょう。そして、それをやるための障害を少しずつ乗り越えていくのです。そうやって3年もやれば良い感じになってきます。そのぐらいかかりますが、再構築で3年使うよりも、よっぽどマシな結果が得られるでしょう。

まとめ

最近、マイクロサービス化のご相談をいただくことがありますが、僕は技術的な実現手段はなんでもいいと思っています。AWSでもAzureでもオンプレでも。大事なのは会社の戦略プロダクトとしてITサービスを捉えてもらい、会社の営みとして持続的にITサービスの提供を行うようにしていくことです。これが僕の考えるマイクロサービス化です。