連載
» 2019年12月05日 05時00分 公開

KubeCon+CloudNativeCon North America 2019報告(2):国防総省がKubernetesとIstioでDevSecOps基盤を構築、「ウォーターフォール文化を変える」 (1/2)

2019年11月にCloud Native Computing Foundation(CNCF)が米サンディエゴで開催したイベント「KubeCon+CloudNativeCon North America 2019」では、米国防総省がKubernetesの広範な採用を進めていることを明らかにした。

[三木泉,@IT]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

 2019年11月にCloud Native Computing Foundation(CNCF)が米サンディエゴで開催したイベント「KubeCon+CloudNativeCon North America 2019」では、米国防総省がKubernetesの広範な採用を進めていることを明らかにした。

 目的は明確で、技術変化が加速化するこの分野において、戦闘システムから業務支援システムにしても、ソフトウェアの更新や新規展開に数年間をかけているようなウォーターフォール型開発思考では、時代に取り残されるからだという。

米空軍チーフソフトウェアオフィサーで、国防総省のDevSecOpsイニシアチブを共同で率いるニコラス・チャイラン氏

 説明したニコラス・チャイラン(Nicholas Chaillan)氏は、米空軍が初めて設けたチーフソフトウェアオフィサーの職を担っている。また、国防総省のCIOと共に、陸・海・空軍を含む、同省全体のDevSecOpsへの取り組みを率いているという。その要となるのが、Kubernetesとそのエコシステムの全面採用だ。これにより、国防総省はインフラとアプリケーションプラットフォームを切り離し、ベンダーロックインを避けたマルチクラウド戦略を進めていくと説明した。

 国防総省に関しては、2019年10月末にMicrosoftが「JEDI(Joint Enterprise Defense Infrastructure)」と呼ばれる契約を同省から受注したことが話題になっている。Microsoftがこの、10年間で最大100億ドルに達する契約を獲得したことは事実としても、同省ではAmazon Web Services(AWS)のGovCloudも使っている。さらにチャイラン氏の説明したDevSecOpsへの取り組みが順調に進むならば、長期的な「勝者」は特定のクラウドベンダーではなくKubernetesということになるのかもしれない。

 実際、チャイラン氏は同イベントで、(クラウドを含め、)「あらゆるレベルでベンダーロックインを回避する」と繰り返し述べ、これがKubernetesを推進する重要な理由だと強調した。また、JEDIに関する質問に対しても、「現時点で複数のクラウド事業者を使っているし、今後もこれを続けていく」と答えた。

ソフトウェアデリバリーは3〜10年の単位だった

 空軍は、チャイラン氏たちの取り組み以前から、「Kessel Run」というCI/CD(継続的インテグレーション/継続的デリバリー)プロジェクトを推進してきた。

 「このプロジェクトは空軍にとって大きな価値をもたらしてきた。しかし、エンタープライズシステム(より一般的な業務支援システム)にも対象を広げなければならない。私たちは空軍だが、陸軍、海軍を含め、国防総省における全てのソフトウェア開発の変革をサポートしている」

 チャイラン氏が16カ月前に国防総省の任務に就いたとき、同省におけるITは次のような状態だったという。

  • ソフトウェア開発は大部分がウォーターフォール型で、新規ソフトウェアのデリバリーは3〜10年を要し、技術進歩に全く追い付いていけない
  • DoDの契約業者にも、アジャイルやDevOpsの文化を持っているところは少ない
  • 省においてソフトウェアの本番運用への移行を認定するプロセスである「ATO(Authority To Operate)」のプロセスも、大部分が手動で、平均8カ月かかる

 これでは現在の状況に全く対応できない。そこでチャイラン氏たちが始めたのが、「Enterprise DevSecOpsイニシアチブ」。これは国防総省のあらゆるシステムを対象とし、「Unclassified」 「Classified」「Top Secret」の3分類全てをカバーするソフトウェア開発・運用基盤だ。

 インフラについては「Cloud One」、その上の開発・運用プラットフォームについては「Platform One」と名付けられた省内のチームが担当、「インフラレイヤーからプラットフォームレイヤーを抽象化し、迅速なプロトタイピングを実現する」という。

「オープン」と「ベンダーロックイン回避」にこだわる

 DevSecOpsを実現するプラットフォームレイヤーの基盤としては、Kubernetesによるオーケストレーションにサービスメッシュ(現在のところIstio)を組み合わせている。

 チャイラン氏は繰り返し、「ベンダーロックインの回避」という言葉を持ち出し、Kubernetesの良さは、クラウドネイティブなアプリケーション構築・運用の包括的なエコシステムを、特定ベンダーに依存しない形で構築できることを指摘した。

 「Kubernetes、OCI準拠のコンテナ、CNCF認定のKubernetesディストリビューション、サービスメッシュ、その上のミドルウェアと、各レイヤーで製品を入れ替えられる形で構築している」

 例えばKubernetesディストリビューションとして、「Pivotal Kubernetes Service」「Red Hat OpenShift」などの名前を口にするが、特定の製品だけを使うということはなく、また事実上特定の製品のみが備える機能は使わない方針だという。

 より詳しいレイヤーの構成は図のようになっている。「インフラレイヤー」「プラットフォームレイヤー」「CI/CDレイヤー」「サービスメッシュレイヤー」と積み上がり、その上にアプリケーションレイヤーが乗る。

国防総省のDevSecOps基盤では、これらのレイヤーを明確に分離することが出発点
       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。