クラウド・ネイティブ・コンピューティングへの取り組みが、さまざまな局面で並行して進み大きなうねりへと成長する兆しを見せている。ユーザーは、進行しつつあるこの動きをどう捉えどのように考えて未来に備えればよいか。ISO IEC JTC1/SC38の専門委員としてクラウドの国際標準の策定にも従事する日本IBMの樽澤広亨氏に話をうかがった。
マイクロサービスは
あえて複雑なことをやっている
IS magazine（以下、IS） 日本におけるクラウド・ネイティブ・コンピューティングの普及状況をどのように見ていますか。
樽澤 この3?4年、話題の中心であったコンテナへの関心は当然のこととして、Kubernetesやマイクロサービスへの関心も非常に高い、と見ています。しかし、実際の適用となると、Webサービス企業と既存の中・大企業との間にはかなりの温度差があり、2極化している印象です。Webサービス企業は、最初からマイクロサービスやサーバーレスといった新たなアーキテクチャに取り組むケースが多いのですが、既存の企業は、従来からのシステム資産や活動中の開発・運用チームがあるので、どうしても適用は遅くなってしまいがちです。市場全体で見れば、多くの企業が関心を寄せるものの、本番システムへの大規模な適用を果たしたケースは多くはない状況です。
IS システムのマイクロサービス化を実践するにあたって、「対象となるのはシステムが複雑な場合で、単純なシステムには向かない」と、樽澤さんは講演などで解説されています（図表1）。複雑なシステムと単純なシステムを見分けるポイントは何でしょうか。
樽澤 それに触れる前に1つ指摘しておきたいのは、マイクロサービスはかなり誤解されている面がある、ということです。その最たるものは、マイクロサービスにするとシステムが早く作れる、とか、開発・運用にかかるコストが安くあがる、というものですが、マイクロサービスのスタイルでシステムを構築するのは、実際はかなり大変です。
マイクロサービスでは、システムのモジュール化を実現するために、あえて複雑なことをやっています。モジュール化のために、さまざまな手立てを必要とするわけです（図表2）。それゆえ、ほんとうにマイクロサービス化する価値があるのか、それを見極めて適用する必要があるのです。そしてその見極めの切り口が、システムが複雑か単純か、ということなのです。
資料：「Testing Strategies in a Microservice Architecture」
複雑さの例としては、大規模な開発チームを必要とするシステム、複数のビジネスに跨ったシステム、多様な連携が不可欠なシステム、スケーラビリティを要するシステム、などを挙げることができます。
とは言え、その複雑さ・単純さを見極めて判断しゴーサインを出すのは、誰が、どのような判断基準のもとで行うか、とてもむずかしい問題です。Webサービス企業はマイクロサービスで始めることに議論の余地はないかもしれませんが、既存の企業では、いろいろな要素を考慮しなければならず、簡単にはいきません。
今、マイクロサービスの事例として紹介されている多くは、Webサービスの提供や活用に携わるスタートアップ系か、この10年ほどの間に登場して大企業へと成長したデジタルカンパニーが中心です。従来からの中・大企業の事例もありますが、その数も適用範囲も限定的です。
トップダウンの
リーダーシップが不可欠
IS 樽澤さんご自身はどのように考えていますか。
樽澤 誰がゴーサインを出すのかという点については、マイクロサービス化へ舵を切った既存の企業の例をみると、じつはボトムアップではなく、トップダウンで実施されています。PoC（Proof of Concept：概念実証）に取り組む既存の企業が、次のステップとして本番システムへの本格展開を狙うならば、CEOやCIOなどCxOによる推進力が必要なのです。
その理由は、マイクロサービス化の取り組みを進めると、組織改革や業務改革へと発展していくことが多く、大がかりなものになるからです。ステークホルダーが多いために、一部の現場が推進役となるボトムアップのアプローチでは、どうしても限界が出てくるのです。既存の企業、とくに大企業ではトップダウンのリーダーシップが絶対に必要になる、というのが私の印象です。
IS 複雑か単純か、の判断基準についてはどうですか。
樽澤 先ほど複雑さの例を挙げましたが、端的に言えば、業務が複雑かそうでないか、が判断のポイントだろうと思います。どこの企業でも既存の業務と既存のシステムがあり、それらが複雑に絡み合って業務が進んでいきます。これをICTの観点から捉えると、複雑な業務にはさまざまなICTが適用されて統合され、システムも複雑になっています。ポイントは、そうした複雑さが必要か、ICTの統合が不可欠かで、あえて統合する必要のないシステムは、マイクロサービス化の対象になると言えます。
継続的デリバリーのニーズに応える
マイクロサービス
IS 新規にシステムを作るときはどうでしょう。何かマイクロサービス化の目安になるものはありますか。
樽澤 企業のシステムは、基幹システムを中心にモノリス（一枚岩）で構築されているものが多く、そのコア部分は数十年、ほとんど変わらないものが大半です。そして、企業が新商品を市場に投入するときは新しいシステムが必要になりますが、その開発を、基幹系のトラディッショナルな業務システムと新しいプロセスとを組み合わせて行うような方法があるかと思います。
そうした商品開発は、昨日今日のことではなく10年以上前からありますが、当時は基幹システムと新しいプロセスとをメッセージ・ハブでつないでシステムを連携させていました。しかし現在は、新商品のシステムをリリースしたら、そのあとの商品やサービスの改訂に合わせてすぐに改修や拡張を行い、即座にリリースしたいという継続的デリバリーのニーズがあります。
そうなると、かつてのテクノロジーでは時間がかかり過ぎ、データの即時連携などにも対応できません。そこで今、こうしたニーズにモダンな形で対応しようとすると、マイクロサービスになるわけです。
開発・運用の繰り返しのなかで
サービス化・洗練化を進める
IS 樽澤さんは、マイクロサービス化はモノリス・ファーストで進めるべき、とお考えですか。
樽澤 モノリス・ファーストで進めるべき、と主張したことはありません。1つの手法としてモノリス・ファーストを紹介してはいますが、中立的な立場です。合う場合は利用すればよいですし、合わない場合はもちろん適用すべきではない。
モノリス・ファーストとは、マイクロサービスの考え方で広く影響を与えているマーチン・ファウラー氏（Martin Fowler）らによって提唱されている手法ですが、モノリス（一枚岩）とはマイクロサービスの対極をなす表現で、従来型アプリケーションのアーキテクチャを指しています。
マイクロサービス化を始めるにあたって、従来型のアプリケーションを先に作ろう（モノリス・ファースト）というのは、クラウド・ネイティブ・アプリケーションでは開発と運用の繰り返しが基本になるので、どうせ繰り返すのなら、最初は勝手知ったる従来型でシステムを作り、その後、改修や追加開発のたびに既存の実装部分を分離・分割してサービス化し、最終的に洗練されたマイクロサービスに到達すればよいという考え方です（図表3）。
IS モノリスからマイクロサービスへと進む、モデル化されたステップなどはあるのでしょうか。
樽澤 状況を踏まえて次に何に取り組むかを見極めることが重要でしょう。
実際にデリバリープロジェクトを始めるときは、予算、期限、期待される成果物などを決めてスタートしますが、最初のリリースまでの期間が短ければ、手早くモノリス・スタイルで作っておいて、その後プロジェクトのオーナーシップがしっかりしていて中長期に渡る反復開発が許されるのであれば、マイクロサービス化を選択すればよいのだと思います。
IS 既存の実装部分からサービスを切り出す手法はありますか。
樽澤 明確なものはないと思いますが、システムを実際に使ってもらってフィードバックを受け、それに基づいて改修や追加開発を検討するなかで、このプロセスは分離したほうがよい、とか、分割してサービス化しよう、という判断が出てくるかと思います。
コンポーネントの分割については、10年前のSOA全盛時にさんざん経験していますので、当時開発し、実践した手法が有益であると主張しているアーキテクトがいます。一般的には、ドメイン（特定の業務領域）のロジックに焦点を置く、ドメイン駆動設計の考え方が役に立つ、と言われています。サービスの切り出しを実践するなかで、いろいろな手法が編み出されてくるだろうと見ています。
マイクロサービス開発のための
理想のチーム編成
IS マイクロサービス化の推進体制については、コンウェイの法則に基づいて、少人数のチーム編成にすべきと指摘されています。
樽澤 コンウェイの法則とは、開発されるシステムの構造は、開発するプロジェクトの体制を反映するというものですから、マイクロサービス・アーキテクチャを適用するプロジェクトでは、開発対象のサービス単位のチーム編成がよいということです。各チームに、UI、アプリケーション、DBの専門家を配置して、マイクロサービスに必要な機能はすべてチーム単独で開発できるように編成します。少人数がよいというのではなく、サービス開発・運用を独力で賄えるチーム編成を目指し、その結果として従来型のチームよりコンパクトになるということだと思います。理想を言えば、マイクロサービスの開発に合ったシステム基盤を整備できるサイト・リライアビリティ・エンジニアリング（SRE）のスキルをもったエンジニアが加わっていることです（図表4、図表5）。
私が知っているお客様事例では、企業のなかに業務チームと基盤チームがあったとしても、業務チームだけでやっていることが多いようです。これは日本に特有のことではなく、グローバルも同様のようです。
IS それは何故でしょうか。
樽澤 1つはカルチャーの壁、もう1つはスキルセットの変化だろうと見ています。カルチャーの壁というのは、従来からあった業務チームと基盤チームの壁のことです。組織編成や仕事のアサイン、評価など解くべき課題が多々あります。解決には、先に挙げた強力なリーダーシップの発揮が必要ですが、和を重んじる日本的なカルチャーのなかではなかなか難しいのが現実だと思います。それで、融合が進んでいかない。
スキルセットの変化について言えば、クラウド・コンピューティングという文脈で、より大きな変革を求められているのが基盤エンジニアだと思います。従来基盤エンジニアが担ってきた基盤構築は、クラウド・サービスによって自動化される時代となりました。クラウドの一般化によって、基盤エンジニアには基盤構築に代わる新たな付加価値サービスの提供が求められています。そのような次世代の基盤エンジニアリングの1つがSREということになります。SREのルーチンを回すにはプログラミングのスキルがどうしても必要になりますが、基盤チームのエンジニアでそれに卓越している人は多くないという事情があるのだと思います。
IS 企業は何を心得るべきですか。
樽澤 ICTシステムはバックオフィスのためのツールではなく、ビジネスをドライブするためのエンジン、との位置づけに考え方を切り替えられるかでしょう。そして、ビジネスのデジタルトランスフォーメーションをICTで具現化できるのがクラウド・ネイティブ・コンピューティングやマイクロサービスですから、それにすばやく取り組めるかどうかが試金石です。
開発から運用までフルカバレッジ
IBMのクラウド・ネイティブ戦略
IS クラウド・ネイティブ・コンピューティングに向けたIBMの戦略はどのようなものですか。
樽澤 IBM Cloud Garage Methodは、お客様のクラウド・ネイティブ・コンピューティングへの移行を支えるコンサルティング・サービスで、実際の開発・運用はこのメソッドに基づいて進めます。このメソッドは、これまでのクラウドチームだけでなく、GBS（グローバル・ビジネス・サービス）も含め“One IBM”で推進していく体制が敷かれています。
製品の観点では、Kubernetesとコンテナに対する迅速かつ積極的な取り組みがあります。IBM CloudのKubernetes機能であるIBM Cloud Kubernetes Service (IKS)は、2017年5月にはKubernetes機能をリリースし、昨年12月より東京のIBM Cloudデータセンターでも利用可能になっています。現在、多くのクラウド・ベンダーがKubernetesやコンテナのサポートを謳っていますが、IKSのリリースは他社に比較して極めて早い対応となっています。対応時期だけではなく、パブリック・クラウドからオンプレミスまで、ハイブリッド・クラウドでKubernetesを利用できるラインナップを要しているのもIBM Cloudの特長です。
日本のお客様は、パフォーマンスやセキュリティについて高いレベルのご要望をおもちのことが多いのですが、そのようなニーズに対応するためのコンテナの稼働環境としてベアメタル・サーバーをご提供しています。このベアメタル・サーバーでは、サーバーの基盤上にセキュリティチップを埋め込んでおり、BIOSやOSのカーネルの脆弱性チェックを終えてからコンテナ・アプリケーションを動かすような高度な脆弱性対応の仕組みを備えています。ベアメタルのコンテナ・サポートは既に東京のIBM Cloudデータセンターでご利用可能になっています。また、現在、IBM Cloudデータセンターではマルチゾーン化を進めており、今後さらなる高可用性への対応も予定しています。
IBM Cloudは、稼働環境としてのKubernetesサービスだけでなく、開発・運用を支援するためのDevOps機能も提供します。オープンな開発・運用ツールを素早くツール・チェーンに組み込むことが可能なOpen Toolchainsを中心に、多様なニーズに応じた開発・運用環境の素早い準備とシームレスな開発・運用作業を実現します。IBM Cloudは開発から運用までフルカバレッジでクラウド・ネイティブ開発をご支援しています（図表6）。
［IS magazine No.20（2018年7月）掲載］
