パート 1: マイクロサービス：技術、ビジネス、組織設計？その全てです

バケツ1杯のレゴがあれば、どんな物語でも伝えることができる。飛行機、ドラゴン、海賊船など、想像できるものなら何でも作ることができる。
クリストファー・ミラー

デジタルトランスフォーメーションの特徴の1つは、スピードと俊敏性の向上です。データとアルゴリズムを使用して、より迅速に意思決定を行う必要があります。新しい収益源を獲得し、顧客体験を向上させるために、デジタルサービスを迅速に作成する必要があります。CTO やチーフアーキテクト（または AWS）が、自社のビジネスを救い、俊敏性、革新性を高め、世界の飢餓を解決するマイクロサービスと呼ばれる新しいソフトウェア・アーキテクチャについて熱く語っているのを聞いたことがあるかもしれません。マイクロサービスアーキテクチャの技術的側面については多くのことが書かれていますが、マイクロサービスの非技術的側面（ビジネス、組織など）は、それほどの頻度や熱量でカバーされていません。マイクロサービスの非技術的な側面を取り上げる前に、技術的な部分も誰にでも分かる言葉で説明し、ビジネス価値との関連を説明する価値があると思います。

デジタルの概念をより良く理解する為に、ソフトウェアシステムに物理的な例えを使うと想像しやすいと思います。あなたの台所のミキサーがパンの生地こね器と一体型だと想像してください。その組合せを変えるには、ノコギリを使って生地こね機を取り外し、ミキサーを溶接する必要があります。試しに電源を入れるとミキサーが激しく揺れて、カウンターからあなたのつま先の上に落ち、軸がずれていたことに気付きます。そこで、ミキサーの軸が真っ直ぐになるまで調整を繰り返します。

一方で、アタッチメントの部品をすばやく交換したり、新しい部品を追加したりできるミキサーがあるとします。この様な仕組みになっていない物を買うのは馬鹿げた事だと思うでしょう。しかし、ほとんどのソフトウェアシステムはこのように設計されていません。

信じられませんか？では、IT部門の同僚と仕事をしたことはあるでしょうか。彼らに要求した小さな変更にアプリケーション全体のテストが必要で、再テストには3か月かかると言われた事はありませんか？（私はこれと全く同じ事を顧客に伝えなければならない事がありました。）そうであれば、あなたのシステムはマイクロサービスやモジュラーアーキテクチャとは逆のもの、俗に言うモノリシックアーキテクチャです。モノリシックアプリケーションは、糸（プログラムコード）とガムテープ（データ）が絡み合ったボールの様な物です。変更するには、デジタルにおける脳外科手術並の対応をするか、バーチャルなノコギリを使う必要があります。

マイクロサービスは、ソフトウェアおよびハードウェアコンポーネントのモジュール性と独立性を重視する、技術的なアーキテクチャアプローチです。分離と独立性は間違いなく最も重要な特性です。物理的な物質が同じ空間を共有できないのと同様に、マイクロサービスでも同じデジタル空間を共有すべきではありません。もし、小さな子供がいれば、同じおもちゃを共有させることはケンカの元だということが分かるでしょう。したがって、馬鹿げた事に思うでしょうが、私がしたように、それぞれ子供のために同じおもちゃを買うことになります。ITの世界では、全員に同じおもちゃを買うことは、全員に自分のサーバーやデータセンターを与えることです。これは非常に高価に思えますが、そうでなければ変更管理委員会の様な文明化された議論の場で「ケンカする事」につながるでしょう。クラウドの世界では、従量課金のモデルとサーバレスと呼ばれるサーバを全く気にしなくてもよい新しいパラダイムにより、経済性は変化します。全員にPlayStationを！

では、これがビジネスの俊敏性、スピード、価値とどのように関係するのでしょうか。 別の例を使ってみましょう、デジタルの例です。CEOが消費者との直接取引はフォーカスすべき重要なチャネルであると宣言しました。新しい e コマースプラットフォームが作成されました。顧客は最初はワクワクしていましたが、商品のレコメンデーションがおかしいと不満を言い始めました。また、新しい部署がサイトに新しいカテゴリを作成したいと考えています。州の税務処理の基準が変更されたため、税の計算を支払い時に変更する必要があります。問題は、これらすべての変更をどのように行うかです。さまざまなシステムコンポーネントのコードの変更を調整し、それらが何も壊さないようにするためには、膨大なスケジュールを作成する必要があります。これらの変更を展開できる次のタイミングは、数か月後になるでしょう。

ただし、eコマースプラットフォームが独立したビルディングブロックに分割されていれば、各変更は他のチームと調整することなく行うことができます。これがマイクロサービスの利点であり、Amazon.com の構築方法にもなっています。

2010年、私はカンファレンスに出席し、Amazon.com が何千ものマイクロサービスとしてどのように設計されているかという話を初めて聞きました。その時、Amazon.comは11.6秒ごとに変更をリリースしていました！ そんなことは不可能だ、と思ったことを覚えています。今日では、Amazon.com の変更はおよそ数秒ごとに 1 回行われています。つまり、Amazonは成長と拡大を続けながら、より頻繁な変更を実現できているという事です。驚くべきことです。しかし、この成果は技術的なアーキテクチャのみによるものではありません。次の一連の記事で取り上げる、ビジネスと組織のアーキテクチャによるものです。

イノベーションを止めないで！

ジョー

著者について

Joe Chung

Joe は 2016 年 11 月にエンタープライズストラテジストおよびエバンジェリストとして AWS に入社しました。エンタープライズのテクノロジーエグゼクティブと協力して、クラウドがどのようにスピードと俊敏性を向上させ、より多くのリソースを顧客に提供できるかについての経験と戦略を共有しています。ジョーはミシガン大学アナーバー校で機械工学の学士号を取得しました。また、ノースウェスタン大学のケロッグ経営大学院で経営学修士号を取得しています。

翻訳は Solutions Architect 多田が担当しました。原文はこちらです。