DevOps実践とDevOpsのカギとなるマイクロサービスを生かし切る秘訣とは？：ITサービス開発競争を勝ち残るための必須要件
X-Techに代表されるデジタルトランスフォーメーションのトレンドが進展し、業種・規模を問わず、多くの企業がソフトウェアの戦いを強いられている。この戦いを勝ち抜くための最大のポイントは、ニーズの変化に応える「スピード」。これを受けて、今あらためてDevOpsが注目されているが、その実践のカギとなるマイクロサービスアーキテクチャについては、まだ十分に理解が浸透しているとは言えない状況だ。では今あらためてDevOpsとは何か？ マイクロサービスアークテクチャとは何か？――両者に深い知見を持つレッドハットに話を聞いた。
DevOpsにありがちな誤解とは？
ITの力で新たな価値や利便性を生み出すデジタルトランスフォーメーション（以下、DX）のトレンドが進展している。特にX-Techに象徴されるITサービスの競争は各業種で激化しており、競合に先んじてサービス価値を打ち出す「スピード」が差別化の重要な要因となっている。
こうした中、ビジネス要求に迅速に応える手段として、今あらためてDevOpsが注目を集めている。特に昨今はDXトレンドの進展を背景に、大企業での取り組み事例も増えつつある。だが着手してはみたものの、成果に結び付いていないケースは多い。レッドハットのテクニカルセールス本部 シニアソリューションアーキテクトの須江信洋氏は、「DevOpsがうまくいかないことの背景には、いくつかの誤解があります」と指摘する。
「よくある誤解は、DevOpsを単なる『システム開発のプロセス』としてのみ捉えてしまうことです。DevOpsを正しく理解するためには、『顧客接点となるSoE（System of Engagement）領域のシステム』の重要性が増したことで、“ニーズに応えるスピード”が重視されるようになったこと、またそのために、プロセスだけではなく、複数の要素が変化している点に着目することが重要です」
具体的には、アプリケーションアーキテクチャは「機能変更が難しいモノリシック（一枚岩）なシステムから、単機能のサービスを組み合わせて1つのアプリケーションを作ることで変更容易性を高めるマイクロサービスアーキテクチャへ」、デプロイの単位は「準備に時間がかかる物理サーバから、スピーディー・柔軟に用意できる仮想サーバ、さらにアプリケーションをパッケージングすることで環境を選ばず迅速にデプロイできるコンテナの利用へ」、インフラは「自社データセンターから、ホスティング等によるマネージド環境、さらにクラウドへ」と変化してきている。
「DevOpsという“プロセス”だけを見てしまうと、正しい理解は難しくなります。“ビジネス要求に迅速に応える”ために、プロセスから、アプリケーションアーキテクチャ、デプロイの在り方、インフラまで、全ての要素が変化していると捉えることが大切です」
そして何より重要なのが「ビジネスの視点」を持つことだ。ニーズに即応するといっても、ニーズの変化が速く競合も多い中では、「どんなサービスが顧客の支持を獲得するのか」“正解”が分からない。この点で、須江氏は「リーンスタートアップの考え方を理解することが大切です」と勧める。
「リーンスタートアップとは『そもそも何を作るべきか分からない』状態から、科学的に物事を進めていくためのマネジメントの方法論です。つまり、顧客が何を価値として評価するか、仮説を立て、仮説に基づいてアプリケーションを開発・提供し、その反響を定量的に測定し、仮説の妥当性を検証して、次の仮説にフィードバックする。このループを短期間で回し、トライ＆エラーを繰り返すことでビジネスの成果につながる“正解”を模索していく。そのためのプロセスがDevOpsであり、DevOps実践のカギとなる手段としてのマイクロサービスアーキテクチャやコンテナがあるのです」
だがDevOpsは、人や文化という側面が抜け落ちてもうまくいかない。以上のような技術・ツール、プロセスはトレーニングして習熟度を上げれば対応できるが、人・文化の問題はトレーニングだけで変えることは難しいためだ。そこで、さらに2つの要素が求められる。1つは経営層のコミットメントだ。
「DevOpsはニーズに即応することでビジネスの成果を上げるための取り組みです。『顧客に求められている機能』を迅速に開発・提供できるよう、経営層・管理層がきちんとリードする必要があります。例えば従来は、ユーザーが求めていない過剰な品質を追求してしまったり、求められていない機能を追加してしまったりしがちでした。そうしたスタンスを改めさせ、あくまでユーザーエクスペリエンスの視点で品質を担保するようリードすることが大切です」
そのために求められるのがもう1つの要素、DevOpsを実践できるゴール・KPIの設定だ。開発や機能変更要求へのスピーディーな対応が重視される開発部門、安定性の担保が重視される運用部門といった具合に両者のKPIが相反すると、迅速な開発・リリースの阻害要因となってしまう。そこで、例えば『ITサービスで獲得した利益』をゴールに設定し、利益という1つのゴールに向けて両者が協業できるようにする。
「カギは、共通のゴールを達成するための定量的なルールを設けることです。その点、GoogleのSRE（Site Reliability Engineering）における管理手法は参考になります。具体的には、エラーバジェットと呼ぶ『障害によるシステム停止時間の枠』を決めておき、その枠を使い切ったら新機能のリリースを禁止します。つまり新機能を求めるサービス企画側と、実際にサービスを動かす開発・運用側がリスクをシェアすることになるのです。逆に使っていなかったらチャレンジしていないことになります。サービスの利益に最終責任を持つビジネスオーナーも、ただいたずらに『障害を起こすな』と求めるばかりではなくなり、障害を起こさずに機能改善を進めることを目指すようになります」
以上のように、DevOpsは「ビジネスの成果を迅速に獲得する」ための取り組みであり、リーンスタートアップの考え方の下、「人・文化」「技術、ツール、アーキテクチャ」「プロセス」全てがかみ合うことが成功の要件となるわけだ。
DevOpsの導入を検討しながら、一歩が踏み出せない企業や何から始めてよいか分からない企業が日本にはまだまだ多い。レッドハットは「DevOpsディスカバリーワークショップ」を昨年より提供開始している。このセッションでは、ビジネス・開発・運用部門に向けて、DevOpsの目的や背景、主要成功要因、技術要素を解説することを通じて、DevOpsの理解度向上を図るとともに、現状分析を行い、成熟度判定から実践レポートを提供するという。
マイクロサービスアーキテクチャの「3つの価値」
ではDevOps実践のカギとなる、マイクロサービスアーキテクチャはどのようなメリットをもたらすものなのだろうか？ 須江氏は、 “マイクロサービスの3つの価値”を挙げる。
1.タイムトゥマーケットの速さ（Faster Time to Market）
1つはタイムトゥマーケットの速さだ。単機能のサービスは小さく自律的であるため、素早く開発してデリバリできる。これは従来型の基幹系システムなどによくあるモノリシックなアーキテクチャの特徴と対比させると理解しやすい。
モノリシックなシステムでは、コードベースが大きく、依存関係のチェックやテスト、リリースに時間がかかるのが常だった。金融系のシステムを例にとれば「残高照会」の機能1つを更新するだけでも、システム全体への影響を考慮して、テスト、リリースする必要があった。また、システム全体のローリングアップデートは大掛かりになりやすく、自ずと更新頻度も落ち、塩漬けにされやすいという弊害もある。これに対し、マイクロサービスの場合、個々のサービスはコードベースが小さく、かつ独立してデプロイできるため、短期間でリリースできる。変更要求にも素早い対応が可能だ。
また、小さく分割することでアーキテクチャを分けることもできる。モノリシックなシステムは同じ言語、同じ環境で作らざるを得ないが、マイクロサービスなら、多言語を使った（ポリグロット）プログラミングアプローチが可能だ。
「例えば、決済など高度な安定性が求められる機能ならJavaやScala、Webアプリケーションの一般的な機能ならRuby on RailsやNode.js、機械学習を使う機能ならPythonといったように、1つのシステムでも目的に応じて言語を使い分けることができます。これによって新しい言語が登場しても対応できますし、さまざまな人材を採用しやすくなるメリットもあるのです」
2.効率性（Efficiency）
2つ目は効率性だ。サービスが小さいためデリバリの自動化やモニタリングが容易となる。これはプロジェクトチームの組成・運用に大きく関わってくる。
モノリシックなシステムは対象範囲が大きいため、自ずとプロジェクトチームが大きくなり、役割ごとのサブチームに細分化されてしまいがちだ。プログラマ、オペレータ、DBA、品質保証、ビジネスアナリスト、プロジェクトマネージャなどさまざまな役割のメンバーが複雑に絡み合いながらプロジェクトを進める。こうした体制だと、スキルセットごとにメンバーが固まることで壁ができてしまい、コミュニケーションが阻害されがちな傾向が強い。結果として、プロジェクトの進行も阻害されやすくなってしまう。
これに対してマイクロサービスでは、「役割」ではなく「サービスごと」にチームを編成する。「Two Pizza Team」（食べる量がピザ2枚で足りる程度の人数のチーム）を上限とし、1つのチーム内で、サービス企画から開発、運用管理まで一貫して取り組む。「開発して運用部門に引き渡す」のではなく、「チーム内で作ったものをずっとサポートしていく」体制だ。
「ポイントは、チームメンバーがプログラミングだけ、運用管理だけといった具合に、単一のスキルを持つメンバーの集まりではない点です。限られた人数のチームでプロジェクトを進めるためには、各メンバーが複数のスキルセットを持ち、いろいろな役割をマルチでこなすことが求められます。また、マイクロサービスごとのコードの行数はモノリシックなシステムと比較すると小さくなる（数百行程度で収まることも多い）ため、こうした体制でプロジェクトを進めると全員がコード全体を見渡すことができるようになります。当然、メンテナンスも機能改善のキャッチアップも非常に効率が良くなります」
3.スケーラビリティ(Scalability)
3つ目はスケーラビリティ。細かい粒度でスケーラビリティを制御できるため、アプリケーション全体でのリソース利用を最適化しやすくなる。つまり、モノリシックなシステムの場合はアプリケーション単位で全体をスケールアウトすることしかできないのに対し、マイクロサービスの場合、サービス単位で細かくリソースを調整できるのだ。
例えば金融業務のアプリケーションにおいて、典型的なユーザーは「残高照会機能」を1日に何十回と利用するが、「振込先の登録機能」は年数回しか利用しないというケースがあったとする。モノリシックなシステムでは最も使われる機能に合わせて全体のキャパシティを調整するため、「残高照会機能」の要求水準が高くなってスケールアウトさせると、ほとんど利用されない「振込先の登録機能」までスケールアウトされてしまう。実際、CPU利用率が常に5%程度でしかないシステムも多いのだという。
これに対してマイクロサービスアーキテクチャでは、必要な機能（サービス）を必要な分だけスケールアウトできる。普段使わない機能は停止させておき必要になったら起動させる、処理量のピークに合わせて自動的にスケールさせ、ピークが過ぎたら自動的にシュリンクさせるといったきめ細かい制御も可能だ。
「従って、マイクロサービスアーキテクチャではモノリシックなシステムで行っていたようなサイジングは行わないことが多いようです。前述のように、新しいサービスが今後どのように市場に受け止められるのか予想することはほぼ不可能ですが、マイクロサービスアーキテクチャなら、サービスの成長具合に応じて効率良くリソースを調整することができるのです」
以上、3つの価値からは、顧客の反響を見ながらサービスを迅速に開発・改善するDevOpsにおいてマイクロサービスアーキテクチャがいかに有効か、非常に具体的に理解できる。だが、いいことずくめに思えるマイクロサービスも、やはり万能ではない。須江氏は、マイクロサービスの4つの課題を挙げる。
Copyright © ITmedia, Inc. All Rights Reserved.
提供：レッドハット株式会社
アイティメディア営業企画／制作：＠IT 編集部／掲載内容有効期限：2017年9月29日
