一般企業における、コンテナ、DevOps、マイクロサービスへの道筋：レッドハットのクレイグ・ムジラ氏に聞く

コンテナ、DevOps、アプリケーションのマイクロサービス化への取り組みについては、まだきっかけをつかめていない企業が多いのではないだろうか。そこで米レッドハットのアプリケーションプラットフォームビジネス担当シニアバイスプレジデント、クレイグ・ムジラ（Craig Muzilla）氏に、一般企業におけるアプリケーション開発・運用の新たな世界へのシナリオについて聞いた。

[PR/＠IT]

PR

　コンテナ、DevOps、アプリケーションのマイクロサービス化に関しては、多様な情報が手に入るものの、組織としての取り組みになると、きっかけをつかめないままのところがまだ多いのではないだろうか。そこで米レッドハットのアプリケーションプラットフォームビジネス担当シニアバイスプレジデント、クレイグ・ムジラ（Craig Muzilla）氏に、一般企業におけるアプリケーション開発・運用の新たな世界へのシナリオについて聞いた。

　ムジラ氏は、レッドハットのアプリケーションプラットフォーム、ミドルウェア事業の総責任者だ。また、同社の製品全体にわたる開発者向けプログラムを指揮している。聞き手はアイティメディア ＠IT編集部 エグゼクティブエディターの三木泉。

――企業アプリケーション開発者、特にJava開発者は、コンテナをどのように考えればいいと思いますか？

ムジラ氏　コンテナは全ての開発者の仕事を拡張し、ほとんどの開発者はコンテナの利便性を喜ぶと思います。Javaは900万人の開発者が使っています。従って、JVMは今でも非常に重要な存在です。ただし、コンテナの世界ではJVMが、OSに対する抽象化レイヤという役割から離れ、プログラムの実行を助ける役割に移っています。

　Java開発者はコンテナを、デプロイメントに関する、これまでよりも容易で優れた手段として使えます。また、CI／CDといったコンセプトにより、再デプロイメントも楽になります。JVMだけではこうしたことが実現できません。また、どの言語でもコンテナのデプロイ方式に共通化され、デプロイの効率化およびアップデートが容易になります。

　コンテナは決して新しいコンセプトではありません。20年以上も前から存在しています。サンマイクロシステムズのSolarisにもありましたし、レッドハットもRed Hat Enterprise Linux（RHEL）で提供してきました。最近起こっているのは、これを前進させ、さらに使いやすくしようとする動きです。一部で戸惑う人もいるのは分かりますが、心配することはないと思います。

――コンテナの先にあるアプリケーションのマイクロサービス化への戸惑いはあるでしょうね。

ムジラ氏　ええ。マイクロサービス化はこれまでと異なる大きな変化です。ステートフルな機能を盛り込めるということは、多くの動的な言語に比べたJavaのメリットだと思います。ですが、モノリシックではなく、動的なアプリケーションを構築する際に、マイクロサービスという考え方が避けられません。そこでは、マイクロサービス間のコミュニケーションがRESTfulに行われ、従来型のアプリケーションサーバによる制約から解放されるようになります。開発者はこのことを考え、マイクロサービスの世界におけるやり方を理解する必要があります。

　ここで、興味深い点が１つあります。

　マイクロサービスはいろいろな作業をシンプル化してくれます。アプリケーションコンポーネント間を分離し、１つ１つのコンポーネントを、他と切り離してアップデートするなどが可能になり、アプリケーションの変更の影響度を最小化できます。

　一方で、複雑化する部分もあります。マイクロサービスの世界では、密結合はなく、全てが疎結合です。マイクロサービス同士がメッシュ状にやり取りするため、こうしたアプリケーションがどのような振る舞いをするかを理解しなければなりません。これについての直接的なソリューションは、今のところ、どのベンダーからも提供されていません。マイクロサービスが真の意味で成功するためには、こうした点で、アプリケーションのモデリングを支援するツールが必要になります。

――どうすれば、それが実現できるでしょう？

ムジラ氏　例えばオーケストレーションの仕組みのKubernetesですが、現状では「このマイクロサービスとこのマイクロサービスが関係している」ことだけを認識し、まとめてアプリケーションとして展開するなどの作業を実行しています。加えて、「マイクロサービス間でどんなデータがやり取りされているか」といった、より高レイヤの情報を理解することが求められます。このため、新しい仕様を策定し、アプリケーションとしての振る舞いをXMLで記述し、モデリングが行えるようなツールを生み出す必要があります。この問題については、レッドハット社内でも議論が始まっていますが、まだ具体的な動きにはつながっていません。

　このような仕様やツールが登場するまで、アーキテクトは注意深くアプリケーションをモデリングしなければなりません。例えばあるマイクロサービスに修正を加えた際に、これが全体としてのアプリケーションの振る舞いにどのような影響を与えるかについて理解し、対応する必要があります。

　最先端を走っている顧客は、この問題を強く認識しています。一方、大部分の顧客はそこまでマイクロサービスを活用しておらず、こうした問題で悩む段階ではありませんが、コンテナを活用し、日々の改善をすぐに反映できる仕組みが重要です。

既存アプリケーションを動かせることのメリット

――一時期から、コンテナプラットフォームあるいはPaaSで、ステートフルなアプリケーションに対応できるものが出てきたことで、一般企業が段階的にこの新しい世界での取り組みを進められるようになったといえますね。

ムジラ氏　その通りです。初期のPaaSはステートフルアプリケーションに対応していませんでしたが、OpenShiftでは早くから対応していました。企業は既存のJavaアプリケーションをコンテナに移行し、アップデートの容易さというコンテナの利点を活用できます。その上で、ステートレスなアプリケーションを開発し、追加できます。

　OpenShiftが多くの企業に導入されている理由の一つはそこにあります。ユーザー企業は、OpenShiftを導入してすぐに、新旧を問わず多くのアプリケーションで、OpenShiftでのメリットを生かすことができます。

一般企業は、コンテナ利用をどのように進めているか

――コンテナプラットフォームを一般企業がどのように使い始めているか、具体的な事例について聞かせてください。

ムジラ氏　Amadeus、Berclays Bank、United Health Careなど、一般企業がOpenShiftを利用しているケースは多数あります。その多くが、「Red Hat JBoss Enterprise Application Platform（EAP）」で、Javaアプリケーションを活用しています。また、もちろん他言語のアプリケーションも稼働しています。

　Amadeusは航空券予約システムを運営してきた会社ですが、ホテル予約のビジネスに乗り出しています。多様なホテルチェーンのために、クラウドベースの予約システムを構築しています。アジャイルに、素早く事業を動かしていくため、OpenShiftを使ってDevOpsを推進しました。

　Amadeusの開発チームは全員がJava開発者でしたので、新システムもJavaで書いています。しかし、市場投入までの期間は3分の1に短縮できました。

――コンテナプラットフォームを活用した、組織としてのDevOpsの進め方について、典型的なパターンは見出せますか？

ムジラ氏　もちろん、スクラムなどを使って、ウオーターフォールからアジャイルな開発スタイルに移行することで、最大のメリットを得られます。継続的開発を意識したアプリケーション設計をすることで、ソフトウェアを数カ月、さらには数週間単位で展開できるようになります。

　スクラムチームに開発、テスト、運用の各チームが参加し、開発チームが自分たちのアプリケーションやサービスの成果をモニタリングする役割を担うこともよくあります。DevOpsの世界では、開発者がアプリケーションをデプロイすると共に運用のフェーズにも関与し、アプリケーションのパフォーマンスや成果に、ある程度の責任を負うことになります。運用チームは基盤となるプラットフォームを整備し、運用ルールや、スケーリングおよびセキュリティなどに関するベストプラクティスを確立する役割を果たします。開発チームと運用チームが切り離された存在から、お互いに協力し合う存在になるところにも、大きな変化があり、重要な成功要因です。

　これに関して、意外だったことが1つあります。2年くらい前、私はコンテナ活用を主導するのは、ほぼ例外なく開発チームだろうと考えていました。しかし蓋を開けてみると、こうした取り組みの半数が運用チームによって始められていました。今ではその理由が分かりますし、理屈に合っていると思います。

――さらに大きな話題としては、企業全体の文化をどう変えていくか、ソフトウェアをビジネスにどう組み込んでいくかという課題があると思います。どう考えますか？

ムジラ氏　企業はある程度リスクを負うことを考えるべきだと思います。従来は、全ての関係者が承認しなければソフトウェアリリースができませんでした。一方DevOpsで、開発者自身がある程度の責任を負い、自らソフトウェアをWebサービスに投入する体制に移行すると、失敗のリスクも高まります。しかし、失敗からのリカバリを含めて全てを迅速化するのがこの取り組みですから、企業としてこうしたリスクを受け入れなければなりません。

　Netflixのような企業は、これを非常にうまく活用しています。DevOps、マイクロサービスを突き詰め、時には失敗をしながら、どんな競合よりも素早く、自社サービスの機能を進化させ差別化を図っています。

企業における、DevOps展開のシナリオ

――とはいえ、大きな企業では、すぐに体制を変えられないケースが多いと思います。新しい世界への移行を段階的に進めるには、どうすればいいのでしょう？

ムジラ氏　2つのアプローチがあります。

　1つは新しい事業に限定してスタートすることです。Amadeusはとても良い例です。同社は新しい分野に参入し、新しい事業を始めるために、これまでと違うやり方に取り組みました。既存のチームにはこれまでのやり方を継続してもらい、新事業を担当するチームだけにDevOpsや継続的インテグレーションをやらせるわけです。新チームが新しいやり方を確立できた時点で、これを既存のチームに持ち込むことで、企業全体の活動を変えていけます。

　もう1つのアプローチは、逆に既存のアプリケーションの一部を新しい環境に移行するというものです。いくつかの既存アプリケーション、あるいはアプリケーションの一部をコンテナ環境に移行し、試行錯誤を重ねることで、少しずつ変革していくことができます。

　また、日本ではDevOpsディスカバリーワークショップを無償で今年の夏より提供を開始しています。このワークショップは、ビジネスサイド、開発チーム、運用チームが参加し、DevOpsを共有認識して現状の課題を洗い出し、共通目標を立てる支援をするワークショップです。継続的に課題を解決し、DevOpsの成熟度を段階的に上げていくための、非常に良い機会になると思います。

――レッドハットが考えているのは、コンテナプラットフォームだけではなく、ソフトウェアの開発・運用プロセスを構成する要素を包括的に提供し、開発者が自分たちのやるべきことに専念するのを助けることですよね。

ムジラ氏　その通りです。コンテナプラットフォームは基盤となるレイヤであり、スタートポイントです。これがなければ何も始まりません。ですが、私たちの目的は、開発者の人たちの環境を全体的に豊かなものにするということです。アプリケーションライフサイクル管理や、その他のさまざまなツールを提供します。その一つとしてJBoss Middlewareのテーマも、元々これにあります。この製品群でもクラウド対応が進んでいて、コンテナプラットフォーム上で機能を発揮できるよう既に対応しています。オンプレミス、仮想、パブリッククラウド、プライベートクラウド環境と、どの環境でも、同じことができるということも、必要不可欠な点です。

――最後に、新しい世界になかなか踏み込めない人たちや組織へのアドバイスをください。

クレイグ・ムジラ氏（左）と三木泉（右）

ムジラ氏　まずは何かを始めるべきです（笑）。例えばOpenShift Onlineのようなサービスを試しに使って、コンテナのコンセプトに馴れることがすぐにできます。次に、既存アプリケーションの移行、完全に新しいアプリケーションの開発のどちらでもいいので、小規模な開発プロジェクトを進められます。DevOpsや新しい開発手法に関するコンサルティングサービスを提供しているシステムインテグレーターの助けを借りるのも一つの手です。

　レッドハットでも、「Red Hat Open Innovation Labs」というコンサルティングサービスを始めています。顧客が開発したいアプリケーションを選び、開発を進めながらマイクロサービスやアーキテクチャ、DevOpsについて実地で学ぶというものです。日本でも、こうした活動を今後活発化していきます。