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

[齋藤公二，＠IT]

さくらインターネットではコンテナをどう活用しているか

──さくらインターネットではコンテナをどう活用していますか？

　例えば、VPSサービスのバックエンドのAPI環境はコンテナで稼働しています。利用しているコンテナフレームワークは「Apache Mesos」です。テスト環境でJenkinsを使ってチェックを行い、問題がなければデプロイする。それだけでもかなりの時間短縮につながっています。環境を効率的に活用するというメリットもあります。

　その他、社内のエンジニアの間では手元のPCでDockerコンテナを立ち上げることは普通に行われていて、さまざまなシーンでコンテナを活用できるようにしています。

　開発とは少し異なるのですが、私が担当しているもので、クラウドサービスのマニュアルサイトへの適用事例もあります。コンテナを使ってマニュアルの継続的インテグレーション（CI）環境を回しています。

──マニュアルのCI環境というのは、どのようなものですか？

　マニュアルサイトはWordPressで作成されているのですが、「いつ、誰が、どのような意図を持って更新したのか」は把握しにくいところがあります。新機能のリリース時にマニュアルサイトの更新も必要ですが、手作業でWordPressを更新し続けるのには限界もある。新機能が追加されたり、メニューが変わったりしたときに、どんなマニュアルができるか、想像しにくい。

　そこで、まずドキュメントをGitHubで管理するようにして、新しいものを作るときは、ブランチを切ってドキュメントを変更し、画像の修正も加えるようにする。本番環境とレビュー環境は異なるコンテナで稼働していて、ドキュメントをマージすると本番環境にも反映されるという仕組みです。

──ソースコード管理と本番へのデプロイの仕組みをコンテナベースのWordPressに適用したのですね。どんなメリットが得られましたか？

　CIを回しやすくなったことですね。GitHubを通してマニュアルのソースコードを管理するので、サービスの機能改善が複数並行して走っていても、マニュアル更新準備を並行して進めることができます。

Kubernetesの活用は「マネージドサービスで」なのか、「自社管理で」なのか

──先ほど、「業務利用では試行錯誤が続いている」とお話しされてましたが、それは、なぜでしょうか？

　本番環境のコンテナを誰が管理していくかという課題があるからです。管理の課題は大きく2つあって、一つは、コンテナのサーバ側のクラスタ部分を誰が管理するか。もう一つは、基盤の上で動くアプリケーションの管理を誰が行うかです。アプリケーションの部分はおそらく開発者もできると思います。

　ただ、サーバ側、つまりインフラやネットワーク、I/Oなどに関する部分は誰か見るかははっきりしていません。

──コンテナオーケストレーターについては、Kubernetesが標準になってきています。誰がKubernetesの面倒を見るかということでしょうか。

　はい。もともとコンテナの実行環境はばらばらでしたが、2015年にCNCF（Cloud Native Computing Foundation）ができて、その後、各社がばらばらに開発していたコンテナオーケストレーターについてもKubernetes中心で作っていこうと決めました。CNCFは統制がとれていますから、Kubernetes周辺でベンダーロックインは起こらないと思っています。

　ただ、自社の専用サーバ上で稼働させる場合もあれば、ローカルのPC上で稼働させる場合もある。選択肢が多い分、どこで稼働させるかははっきりしていません。

──AWS、Google、Microsoft、IBMなどがKubernetesのマネージドサービスを提供しています。マネージドサービスには、どんなメリット、デメリットがありますか？

　クラウドと同じように考えることができると思います。

　マネージドサービスの場合、Kubernetesの物理ノードに対する管理などを自分たちで面倒を見なくてもいい。その分、サービスを作ることに専念できます。

　デメリットとしては、マネージドサービスを提供するクラウドの“色”が付きやすいこと。ロックインまではいかなくても、関連する機能に依存する部分はどうしても出てきます。

──一方で、自社管理の場合はそれらのメリット、デメリットが逆になるということですか。

　そうですね。自分たちの好きなハードウェアでコンテナを動かすことができます。パブリッククラウドでは提供されていないCPUやメモリ環境、ネットワーク、ストレージを利用できます。手元にある資産を活用することもできる。

　ただ、管理の手間はこれまで以上に増える可能性があります。

──他に、コンテナ／マイクロサービスにおいて今後の課題になるのは、どんなことだと思いますか？

　課題になり始めているのはコンテナのセキュリティです。名前空間を分離する技術は使われていますが、「きちんと分離されているのか」「配布されるコンテナの中に悪意のあるものが混ざっていないか」「誰がコンテナにアクセスしたのか調べられるのか」「ログをきちんと取るにはどうしたらいいのか」などについては、まだ決定打がありません。

　数百、数千規模でスケールするコンテナを誰がどう見るのかは難しい問題で「オープントレーシング」というキーワードでさまざまなツールが発展途上の段階です。

コンテナ／マイクロサービスは、これまでの技術にない面白さがある

──あらためてコンテナ／マイクロサービスが実際のビジネスにもたらすメリットは何でしょうか？

　カナリヤリリースやブルーグリーンデプロイメントなど、ビジネス改善のサイクルを素早く回すための手法をより実践しやすくなったということです。

　冒頭の話に戻りますが、スマートフォンの普及で、サービスを止めずに一部のユーザーに対してだけアプリケーションを新しいバージョンに切り替えて反応を見るということがやりやすくなりました。顧客のフィードバックを見ながら、開発サイクルを早めて、結果として良いプロダクトを作り出していく。コンテナ／マイクロサービスだからこそできることです。

──最後に、コンテナとマイクロサービスでエンジニアの役割はどう変わるか。あらためてお考えをお聞かせください。

　「終わりなき開発」「永遠のリリース」という言葉を使いましたが、開発のスタイル、あるいは文化が大きく変わっています。文化が変われば運用も変わらざるを得ません。当然、その役割も変わっていきます。先ほどもSREの話がありましたが、お客さまとやりとりしながら改善することが、開発でも運用でも行いやすくなりました。これは結果的に開発担当者も運用担当者も幸せにする方法です。

　従来はリリースして見なければ分からなかったものが、今は少しだけ出して様子を見ながらどんどん変えていくことができる。これまでにない面白さです。楽しみながら、新しい変化を当たり前のようにして受け入れていくことが大事だと思います。

特集：日本型デジタルトランスフォーメーション成功への道 〜“他人事”ではないDXの現実解〜

テクノロジーの力を使って新たな価値を創造するデジタルトランスフォーメーション（DX）が各業種で進展している。だが中には単なる業務改善をDXと呼ぶ風潮もあるなど、一般的な日本企業は海外に比べると大幅に後れを取っているのが現実だ。では企業がDXを推進し、差別化の源泉としていくためには、変革に向けて何をそろえ、どのようなステップを踏んでいけばよいのだろうか。本特集ではDXへのロードマップを今あらためて明確化。“他人事”に終始してきたDX実現の方法を、現実的な観点から伝授する。

特集：日本型デジタルトランスフォーメーション成功への道 〜“他人事”ではないDXの現実解〜