現在は「Docker」と「Kubernetes」の成功のおかげで、コンテナ導入に目を向ける企業が増えている。このアプローチに人気があるのは、これが企業にとってデジタルトランスフォーメーション戦略の即戦力となり得るクラウドネイティブアプリケーション開発の助けになるためだ。

　Forrester Researchの報告書「Now Tech:Enterprise Container Platforms, Q2 2018（2018年第2四半期のエンタープライズコンテナプラットフォーム）」は、次のように指摘している。「コンテナ中心型でマイクロサービス指向の、動的に連携するクラウドネイティブ技術は、企業が高度に差別化されたアプリやサービスを開発し、素晴らしいカスタマーエクスペリエンスを創出する一助となる。これがデジタルビジネストランスフォーメーションの重要な要素となっているのは、ソフトウェアデリバリーの高速化やスケールと耐久性、柔軟性および実装の向上が約束されることによる」

コンテナ化に伴うアジャイルへの移行

　この報告書では、主要なエンタープライズコンテナプラットフォームの一つとして、「Red Hat OpenShift」を取り上げている。同製品を事業のデジタル化のために使っている企業の一つに、グローバル情報分析企業のElsevierがある。

　他の組織と同様に、ElsevierもSOAからスタートしてソフトウェア開発のアジャイル化を進める手段としてコンテナを利用した。

　Elsevierのソフトウェアエンジニアリング担当ディレクター、トム・ペリー氏によると、同社は従来型のSOAからスタートしたが、これはあまり同社の支えにはならなかった。「私が2015年に入社した当時、Elsevierは中途半端なSOAを使っていた。これはあまり構造化されておらず、しかもプロプライエタリだった」

　そのためElsevierのソフトウェアチームが再利用可能コンポーネントを開発するのは難しく、それが変化のペースを鈍らせる原因となった。「われわれが使っていたのは、何でも屋的なモノリシックアプリケーションだった。それに順応しようとするたびに大きな動きになった」とペリー氏は振り返る。

　当時、同社はコンテンツの販売からコンテンツに乗せたサービスの販売へと切り替える過程にあった。ビジネスの転換と同時に、ElsevierはITに対するアプローチも転換させ、データセンターを閉鎖してAmazon Web Services（AWS）のクラウドに移行した。

　ペリー氏はビジネスの進化に対応できるアーキテクチャを望んでいた。「われわれは、アプリケーションが相互にどう通信するかに目を向ける代わりに、エンドツーエンドのビジネスプロセスを横断するデータアクセスを求めた」。Elsevierはこれを達成するために、社内のシステムとSalesforceのようなSaaSの緩い組み合わせを必要とした。

　コンテナプラットフォームが継続的に進化することを前提として、ElsevierはSOAからハイブリッド性の強いコンテナアーキテクチャへの移行に着手するため、「Red Hat Fuse」を試した。だが「物事が向かう方向性は見えたものの、この技術はエンタープライズにとっての十分な成熟とは程遠かった」。

　この技術の継続的な進化に合わせて、Elsevierも多くのことを学習する必要があった。コンテナの導入を試みた経験から学んだ教訓の一つは、APIとサービスを公開することにより、多大なセキュリティ対策が求められるということだった。「セキュリティは切り離すべきだった」とペリー氏は言う。

　Red Hat Fuseがうまくいかなかったとすれば、他に何ができるのか。Kubernetesを使ってエンタープライズクラウドプラットフォームを構築することも可能だが、Kubernetesはコア部分にすぎないとペリー氏は言う。Elsevierは単体の製品を望み、結果として「Red Hat OpenShiftContainer Platform」を選定した。「われわれは自分たちのコードをピックアップして、それを別のプラットフォームに導入できるオールインワンプラットフォームを手にした」（ペリー氏）

　同社はまず、この新しいプラットフォームをマーケティングと広告システムに利用した。両システムともそれまでは、オンプレミスソフトウェアとSaaSを使っていた。この構成についてペリー氏は、「企業データへのアクセスを提供し、将来的な再利用のためにAPIでセットを公開することに目を向けた」と説明する。

　Red Hat Fuseと違って、このアーキテクチャはコンテナで稼働するマイクロサービスをベースとしていた。ここではロジック機能しか実行しないことから、追加的なセキュリティについて心配する必要はない。「われわれはAPIゲートウェイを利用してセキュリティを管理しているので、サービス側でセキュリティの心配をせずに済む」とペリー氏は言い添えた。

学ぶべき教訓

　APIにセキュリティを組み込む経験を経て、コンテナはあらゆる種類のアプリケーションやワークロードに適しているわけではないとペリー氏は判断した。「コンテナの利用が必ずしも正しい選択とは限らない」

　コンテナを使うべきではない事例には、モノリシックなコードを伴うアプリケーションサーバやデータベースサーバをコンテナで運用しようとする場合などが含まれる。ペリー氏によると、そうしたモノリシックアプリケーションを重量級のサービスとしてコンテナ化しようとしても、大きなメリットはない。

　Elsevierがコンテナから得たもう一つの教訓は、社内のあらゆる部分がクラウドネイティブコンピューティングに対応できるわけではないということだ。アジャイルの開発メソッドは、アプリケーション開発に対するクラウドネイティブアプローチと関連付けられることが多い。

　Elsevierは一部の開発プロジェクトでアジャイルアプローチを使い始めたものの、「組織の中でもスピードは異なる。アジャイルに対応できるサービスもあれば、『Oracle E-Business Suite』のように対応できないものもある」とペリー氏は言い添えた。

　ITにとってはコストの割り当ても問題となる。ペリー氏は自身の経験から、「共有される機能を横断する統合の領域において、コストをどう分配すべきなのかという問題はまだ解決できていない」と話している。

コンプライアンス上の課題

　DevOpsは一般的に、アジャイルソフトウェア開発の手法と併用され、チームにはコードを迅速に開発してデプロイする自由が与えられる。だが貸金サービス企業WorldRemitのクラウドサービス信頼性エンジニアリング責任者、ジョナサン・ホチキス氏によると、マイクロサービスを実行しているコンテナで構築されたクラウドネイティブアーキテクチャでは、スピードとアジャイル性がリスクを伴うこともある。

　マイクロサービスを使ってサーバレス決済システムを構築している同社は、全体の状況を把握するのがますます難しくなった。「うまくやらなければ、DevOpsではシステムが構築されたまま忘れられたり、クラウドを使ってコードがその能力を超えて拡張されたりして、資金が浪費される」とホチキス氏は言う。結果的に、開発されたコードは効率的な拡張ができなくなる。

　ホチキス氏によると、同社の元々のプラットフォームはモノリシック型データベースを使った従来型のWeb電子商取引アーキテクチャとして始まった。「これは拡張性の面では最善のアーキテクチャではなかった。そこでパーツを取り出し、『Microsoft Azure』を使ってマイクロサービスとして開発した」

　残念ながら、WorldRemitは開発したマイクロサービスの一部をドキュメント化できなかった。その一因はチームの文化にあった。同社のソフトウェア開発チームは短期間の編成で、チームの存続期間は18～24カ月だった。「全てのマイクロサービスについて完全に把握しているチームは一つもなかった。それがどう機能するのかも分からなかった」

　そこでWorldRemitはダッシュボードの一元化を提供する「Dynatrace」を選定した。このダッシュボードはAI駆動型のトポロジーを提供し、システムの全コンポーネントを参照できる。「どこかに不具合があると、何がうまくいっていて何がうまくいっていないのかがDynatraceでハイライトされ、障害が起きた理由についてインテリジェントな答えを与えてくれる」とホチキス氏は言う。

　コンプライアンスとDevOpsチームが効率的に働く自由を与えることのバランスは、常に課題となる。

　WorldRemitが経験したように、例えばチームの作業を確実にドキュメント化させるといったある程度のコントロールがなければ、クラウドネイティブアーキテクチャはたちまち管理不能に陥る。

　会社のルールや手順やポリシーを厳格に徹底させると柔軟性が制約されかねない。だが、ベストプラクティスコミュニティーを使って望ましいツールやフレームワークの使用を奨励する方がうまくいくこともある。

　Porsche Informatikはベストプラクティスを推進する技術者のコミュニティーを設置し、そのベストプラクティスをDevOpsチームにフィードバックした。Porsche Informatikは自社のツールがDevOpsチームにとっての第一の選択肢となるよう、できる限り使いやすくすることに努めた。

クラウドネイティブ化

　調査会社RedMonkの共同創業者ジェームズ・ガバナー氏は、英ロンドンで開かれたイベントで講演し、クラウドネイティブアーキテクチャがアプリケーションのデバッグ方法をどう変化させるかを紹介した。「アプリケーションは効率的に管理できるように開発しなければならない。われわれは、プロダクションにおいてデバッグしなければならない環境に移行しつつあり、そのためには観察できることが求められる」とガバナー氏は言う。同氏によると、プロダクションコードの問題に対応するため、トレース、ログ、アプリケーションパフォーマンスモニタリングが活用されているという。

　英Computer Weeklyが話を聞いた企業は、サーバレスコンピューティング、マイクロサービス、コンテナ、DevOpsの世界の中で、どう開発するかを学んでいるようだった。ガバナー氏が正しければ、さらに多くの企業がライブプロダクション環境を横断するコードのテスト開始に適応する必要がある。

　WorldRemitが経験したように、ビジネスではマイクロサービスがどう進化しているかを見極める必要がある。開発者が採用するツールやプログラミング言語やフレームワークは個人的な選択になるかもしれないが、Porsche InformatikのようにDevOpsチームのメンバーがベストプラクティスに関わることは、プロジェクトで推奨される標準やツールを固める一助となり得る。関連記事

https://techtarget.itmedia.co.jp/tt/news/1912/19/news03.html

「Kubernetes as a Service」とは何か

https://techtarget.itmedia.co.jp/tt/news/1904/18/news02.html

Kubernetesベースのディープラーニング環境「Nauta」