「終わりなき開発」「永遠のリリース」が当たり前に――コンテナとマイクロサービスでエンジニアの役割はどう変わるのか：特集：日本型デジタルトランスフォーメーション成功への道（6）（1/2 ページ）

コンテナ、マイクロサービスはエンジニアの働き方や役割にどんな変化をもたらすのか。クラウドネイティブ開発やクラウドアーキテクチャ、データセンター運用などに詳しい、さくらインターネット テクノロジー・エバンジェリストの前佛雅人氏に聞いた。

[齋藤公二，＠IT]

　デジタルトランスフォーメーション（DX）やITインフラのリフト＆シフトの取り組みの中で重要なキーワードとして注目されているものに「コンテナ」と「マイクロサービス」がある。技術としては、コンテナ実行環境の「Docker」と、コンテナオーケストレーションツールの「Kubernetes」が中心になることが多い。またメリットとしては、高速なデプロイやロールバックが実現できること、開発から本番までを一貫した仕組みで管理できること、ポータビリティー性が高いこと、運用を自動化できることなどが挙げられる。

　こうした新しい仕組みは、エンジニアの働き方や役割にどんな変化をもたらすのか。クラウドネイティブ開発やクラウドアーキテクチャ、データセンター運用などに詳しい、さくらインターネット エンジニア／テクノロジー・エバンジェリストの前佛雅人氏に聞いた。

スマホがもたらした「ビジネス環境の変化」に気付いているか

──企業のDXの話が多くなる中で、コンテナやマイクロサービスが注目を集めていますが、最近の動向をどう捉えていますか？

さくらインターネット エンジニア／テクノロジー・エバンジェリスト 前佛雅人氏

　DXの取り組みでは、アジャイルやDevOpsが重要で、その前提となるクラウドの基盤やコンテナ技術を積極的に使っていこうという動きが進んでいると思っています。しかし、その一方で、クラウドやコンテナは使わないという企業もいて、取り組みが二極化しつつあります。

　なぜ二極化するのかというと、分岐点になっているのは「終わりなき開発」や「永遠のリリース」に対する気付きではないかと思っています。従来のようにシステムは納品したら終わりではなく、プロダクトとして継続的に開発しリリースし続けなければならなくなりました。そのことに気付いた企業が、コンテナやマイクロサービスに向かっています。

──「終わりなき開発」「永遠のリリース」とのことですが、なぜ開発し続ける必要が出てきたのでしょうか？

　スマートフォンの登場が転機だと考えています。「Web系」と呼ばれるようなサービスはPCが前提で、使う時間、場所、人が限られていました。ところがスマートフォンが普及すると、Webのサービスを誰もが当たり前のように利用するようになりました。いつでもどこでも使えるので、サービスを止めるわけにもいきません。また、改善し続けなければサービスを使ってもらえなくなります。手で行う作業が多い従来の手法では対応できませんから、アジャイルやDevOpsのような新しい手法を採用して、ビジネスも素早く軌道修正できるようにしたのです。

──確かに、あらゆるサービスがスマホに対応し、スマホで完結できるようになっていますね。

　はい。私も、自宅ではPCを開くことがありません。日常生活を送る上で、PCを開かなくてもさまざまなサービスを利用できるようになったのです。これはすごく大きいことです。従来は、何かしようとするとPCを手に入れる必要がありました。その上でキーボードに習熟し、インターネットの利用方法も学ぶ必要があった。そうした前提が取り払われたということです。当然のことながらサービスを提供するビジネスにも大きな影響を与えます。

──もしPCを前提にした考え方のままなら、ビジネスが立ち行かなくなることも出てくるということでしょうか？

　そうです。いかにサービスを止めずにバージョンアップするか、うまくいかなかったらすぐに差し戻すことができるか、競合他社が同様のサービスを出したらいかに素早く改善して差別化するか。その重要性に気付くか気付かないかが、企業の取り組みの大きな差となって現れ始めていると感じています。

コンテナとマイクロサービスに対する“誤解”とは

──コンテナとマイクロサービスの普及具合についてはどのように感じていらっしゃいますか？

　個人レベルでは、ほとんどのエンジニアが存在を知っています。企業レベルでも認知度はかなり広がってきたと感じています。ただ、業務でどう使うかは試行錯誤している段階です。その中で“誤解”も生まれている状況なのだと思います。

──取り組む企業は、これからどんどん増えていくのでしょうか？

　先ほど言った理由で、増えていかざるを得ないと思います。

　2013年にDockerが発表され、簡単なコマンドで誰でもコンテナが使えるようになりました。Docker以前にもLinux上の名前空間でリソースを分離する技術（Linux Containers）や、そこで分離されたものにリソースを割り当てる技術（Control Groups）はありました。Dockerの登場によってそれらが簡単に使えるようになり、さらにイメージ（Docker Image）を作成して、どこにでも移動しやすくなりました。その上スケールも容易になり、開発のサイクルを回しやすくなった。

　開発者の視点だけではなく、運用の視点でもスケールしやすくなったのは非常に大きいことです。

──作って終わりではなく、本番の運用、つまりビジネスにも直接的に影響を与えるようになったのですね。

　従来もChefなどの構成管理ツールを使って、仮想マシンイメージをコピーして水平展開することはできました。クラウド環境では、それによって多くのトラフィックをさばくことができます。ただ、環境の再現性が完璧ではない面があったんです。

　例えば、仮想マシンイメージのOSのバージョン、セキュリティパッチの適用、ミドルウェアのバージョンアップをどうするかという課題があった。容量も仮想マシンですから数GB〜数十GBと大きく、移動が簡単ではなかった。

　これに対しコンテナは、アプリケーションだけをコピーすることでスケールアウトやバージョンアップの切り替え、差し戻しなどが簡単に素早くできます。ビジネス的なインパクトもより大きいといえます。

──先ほど触れていた“誤解”には、どのようなものがありますか？

　まず、コンテナを仮想サーバの延長線上で考えてしまうことがあると思います。計算資源の効率的な利用や、サーバ集約によるデータセンターの電力抑制といったコスト削減のイメージでコンテナを捉えてしまうのですが、これは間違いです。

　運用についても誤解が多いと感じています。従来のような、納品され完成されたシステムを保守する役割を求めてしまう。そうではなく、運用チームには、日々変わり得る環境の中でいかに開発と連携しながらサービスを維持していくかが求められます。「SRE（Site Reliability Engineering）」という役割がありますが、コンテナやマイクロサービスの運用において重要です。

──仮想サーバなどの従来の仕組みと、コンテナとの使い分けの目安などはありますか。

　分かりやすいのは、スマホアプリで動くサービスかどうかでしょう。従来の障害耐性とは違うものであり、私たちの日常と密接に結び付いたスマホアプリのサービス継続性をどう維持していくか。終わりのないサービス改善を行うためにコンテナの採用は不可欠になってきています。

　もちろん、コンテナがベストかどうかは作っている環境によって変わる場合があります。合う現場もあれば合わない現場もあるでしょう。しかし、新しい選択肢が増え、具体的な成果が出しやすくなったことは確かです。

　実際、先日行われたJapan Container Daysでも、さまざまな企業がコンテナを実ビジネスに適用して、成果を挙げていることが発表されていました。

コンテナ、マイクロサービス、サービスメッシュの関係は

──そもそもコンテナとマイクロサービスは、どう構成するのがよいのでしょうか？

　システムコンテナとアプリケーションコンテナという2つの定義があると思います。

　システムコンテナは、1つのコンテナにアプリケーションなど関連するものをまとめてしまう考え方です。これについては、先ほどの話と矛盾しているように思われるかもしれませんが、仮想サーバの延長線上で考えてもいいでしょう。

　一方アプリケーションコンテナは、1つのコンテナに1つの機能を持たせる考え方。アプリケーションコンテナは、マイクロサービス的な考え方を適用しやすい。

──アプリケーションコンテナをマイクロサービスとして構成していくことは、従来の仮想サーバと、技術的にどういう違いがあるのでしょうか？

　コンテナが伝統的な考え方と大きく違うのは、IPアドレスとホスト名による対応ではないことです。コンテナの中に名前解決の仕組みが入っていて、IPアドレスにかかわらずスケールできるようになっています。また、負荷分散したり、バージョン違いのプログラムをルーティングしたり差し替えたりしてくれます。もちろん、IPアドレスとホスト名をひも付けてシステムコンテナとして管理することもできます。

　システムコンテナはIPアドレスとホスト名が1対1で対応させる場合が多く、アプリケーションコンテナは、Dockerの負荷分散の仕組みやKubernetesのようなコンテナオーケストレーターを使って行います。

　ただ、これらはあくまでもコンテナレイヤーの話です。アプリケーションの切り替えまでは担っていません。最近は、その部分について「Istio」のようなマイクロサービスのオーケストレーションや「Spinnaker」のような継続的デリバリー（CD）プラットフォームが注目を集めています。

──それらは「サービスメッシュ」と呼ばれるものでしょうか。

　サービスメッシュについては、まだ定義がはっきりしていないところがあり、「これぞサービスメッシュ」と呼ばれるものはないのが現状です。

　個人的にはIstioの内部に入っている「Envoy」を使ったアーキテクチャが「サービスメッシュ的なもの」ではないかと思っています。内部で自動的に名前解決したり、ルーティングしたりする機能です。サービスディスカバリーの分野を含む場合もあれば、オブザーバビリティーという言葉で表したりもします。

　幾つかの概念や言葉がありますが、いずれそれらがサービスメッシュに集約されていくのではないでしょうか。現場や利用形態に応じて、求められているサービスメッシュの種類が異なると思っています。