ペアで語られてしまいがちな「マイクロサービス」と「コンテナ」
Amazonには「DevOps」や「マイクロサービス」という言葉が生まれる前から、DevとOpsを統合し、システムはAPIでやりとりするという原則がある。それを長年追求するなかで、開発カルチャーを育んできた。そんなAmazonから開発と運用の理想の形について聞いてみよう。解説してくれるのはAWSジャパンでスタートアップ企業を中心にソリューションアーキテクトとして多くの現場を支援している塚田朗弘氏だ。
キーセンテンスとなるのはAmazonで浸透している「You build it, you run it」。直訳すると「あなたが開発し、あなたが運用する」となるが、要は「開発した人が運用しましょう」ということだ。言い換えると、Amazonがたどり着いたDevOpsの理想形は、「DevとOpsの協調や歩み寄り」などではなく、文字通り「Dev=Ops」であると言える。
近年ではDXが喫緊の課題となり、それに不可欠なものとして開発環境やインフラの最新鋭化が注目されている。この最新鋭化を達成するには何が必要かと考えた時、マイクロサービスとコンテナを思い浮かべる人も多いだろう。しかし、そこには注意が必要だ。塚田氏は次のように説明する。
「確かに、お客様の現場ではマイクロサービスとコンテナがペアで語られることが多いです。しかし前提としてお話ししておきたいのは、これらは基本的に別物だということです。大切なのは目的です。何のために導入するのかを明確にしておく必要があります」
まずはマイクロサービスとコンテナをきちんと区分けするところから始めよう。マイクロサービスは独立性のある小さなサービス群であり、これらで構成されるシステムになる。対極にあるのがモノリシック（なシステム）だ。
マイクロサービスにすることのメリットには、「開発対象を小さくして開発のスピードを高める」「サービスを分離して障害時の影響を極小化する」「開発を分離してコストを管理または最適化する」などがある。
一方コンテナ（主にDocker以降のモダンコンテナ）はアプリケーションの可搬性を高めることや、開発環境と本番環境など、環境の差異をなくすことに役立つ。コンテナは開発者にはとても便利で有益な存在であり、生産性向上や高品質化を実現している。
どちらもあると望ましいものといえるが、マイクロサービスはシステム構造が、コンテナはシステム環境の柔軟性が、それぞれのテーマとなる。混同してしまうと迷走してしまう危険性がある。
大事なのは塚田氏が言うように「何を実現するために導入するのか」という目的だ。塚田氏は「マイクロサービスもコンテナも何らかの目的を達成するための手段であるべきです」と強調する。
実際に塚田氏がマイクロサービスやコンテナで課題を抱えている顧客の開発現場で導入の目的を問うと、明確に答えられないケースも少なくないという。コンテナではなく仮想マシン（Amazon EC2）のほうが向くケースや、マイクロサービスでなくAWS Lambdaなどを使ったファンクション単位の構成のほうが適していたというケースも起こりうる。
「導入の目的やビジネス的な課題をどう解決するかというところにフォーカスする必要があります」と塚田氏は念を押す。
マイクロサービスは技術だけの問題だろうか
マイクロサービスやコンテナといった最新鋭技術を導入することのメリットは多々ある。しかし目的を達成するための手段であるはずの技術が目的化してしまうと本末転倒となりかねない。
例えば、スタートアップのような小さな会社で、システムの規模がさほど大きくなければ、マイクロサービス化してもメリットをあまり享受できないこともある。むしろサービス数が多いことで開発や運用保守の工数が増えてしまう。あるいは、サービス間のメッセージングも増えてしまい、複雑性を高めてしまいかねない。
また、マイクロサービスにすることでデータのオーナーシップが不明瞭になってしまうこともある。加えて、全体として一貫性のない設計に陥ってしまうケースもある。
目的が不明確なままマイクロサービス化を進めてしまった場合、リカバリする方法はあるだろうか。塚田氏は「どこまで進んでしまったかにもよりますが、本当に目的が明確でないなら、やめたほうがいいと思うのが率直なところです。ビジネスであれば目的があり、実現する手段として合理的かどうか検証したうえで判断することが大事です」と話す。
例を挙げよう。当初モノリシックでも成り立っていたシステムが次第に肥大化すると、開発のスピードが落ちるなどの弊害が現れてくる。そこで各チームを小さく保つことでスピードやアジリティを維持したいという目的が浮かんでくる。こういう時に目的を実現する手段としてマイクロサービス化が候補に挙がってくる。
「まずは、課題に対して、『これにはマイクロサービスが合理的である』と論理的に明確に説明がつく状態である必要があります」と塚田氏。明確な目的を掲げ、選択した理由に自信があれば失敗や迷走することなく進んでいく。
なおAmazonがマイクロサービス化を進めている時、冒頭のキーフレーズとなる「You build it, you run it」という概念が生まれた。もともとは2006年、AmazonでCTOを務めるワーナー・ボーゲルズ氏が提唱した。
この言葉は技術だけでなく、組織のありかたにも着眼している。コンウェイの法則（システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう）から、組織の構成がサービスの単位であるべきと導き出される。Amazonでは、それぞれのチームが独立した小さな企業のような存在となり、そのなかに開発も運用も全ての機能を盛り込むようにしようと考えた。それをボーゲルズ氏が「You build it, you run it」（開発する人が運用しよう）と表現したというわけだ。
