通称「魔境」の更改を巡り開発部門と運用部門が対立――NTT Comの仮想サーバ基盤Kubernetes移行の裏側：「腹を割って話す」ことが大切

NTTコミュニケーションズはオンプレミスの仮想サーバ基盤をマネージドKubernetes環境に移行したという。プロジェクト半ばで課題となった部門間のすれ違い、体制面をどう解決に導いたのか、NTTコミュニケーションズでSREを務める船柳孝明氏が語った。

[高橋睦美，＠IT]

　システムの構築、運用に関して何も悩みを抱いていないという人は少数派だろう。NTTコミュニケーションズ（以後、NTT Com）でサイトリライアビリティエンジニアとして、DevOps基盤開発プロジェクトを担当している船柳孝明氏も、システムのマイグレーションに当たってさまざまな悩みに直面した一人だ。

　船柳氏は2021年7〜8月に開催された「Cloud Operator Days Tokyo 2021」の講演「ハイブリッドクラウド移行までの泥臭い道のり」において、2020年7月から2021年3月にかけて実施した、オンプレミス環境からハイブリッドクラウド環境へのシステムマイグレーションで、技術面のみならず技術以外の側面でどのような悩みに直面し、どう解決したかを紹介した。

システム更改を機に、「魔境」の根本的な課題解決に着手

　船柳氏がマイグレーションに取り組んだのは、典型的なオンプレミスのシステムだ。NTT Comの社内環境で動作する仮想マシン基盤で、ネットワークは社内網、対向するシステムも基本的に社内網につながっている。そして、他のシステムやデータベースなど重要なサーバとはDMZ（DeMilitarized Zone）を介して接続することで保護される「境界型セキュリティ」で分離し、セキュリティを保ってきた。

　だが、サポート終了（EOL）に伴う更改の時期がやってきた。「よくある話ですが、先送りにしていたことが災いとなりました。ソフトウェアは開発とともにアップデートしていたのですが、OSやミドルウェアは触れられておらず『魔境』と化していました」（船柳氏）

NTTコミュニケーションズ サイトリライアビリティエンジニア 船柳孝明氏

　システム更改に当たって船柳氏は「そもそも今の構成のままアップデートし、延命していくのが最適解なのだろうか」と根本的な部分を考えることにした。というのも、既存システムには、幾つか課題があったからだ。

　「1つ目の課題は、基盤開発が属人化していたことです。システムの構成管理には『Ansible』を利用していましたが、Ansibleに触れられる人が限られていました。また2つ目の課題として、Ansibleでアップデートを積み重ねてきた結果、環境ごとに挙動が異なってしまっていました」（船柳氏）

　さらに、開発担当、運用担当、環境を用意するシステム担当がそれぞれ縦割りの構造となっており、DevとOpsが分離しているという体制面の課題や、オンプレミス環境に甘えたセキュリティ対策も課題であり、この機に改善したいと考えたという。

移行前に抱えていた課題

開発者と運用者によるDevOpsを目指し、Kubernetesベースの新環境を構想

　船柳氏は「できるところから始めてみよう」というコンセプトで、既存システムのマイグレーションに取り組んだ。

　重視したのは「部署の壁を越えて、基盤の開発者と運用者がワンチームになれること」。その手段として、Infrastructure as Code（IaC）の実現を目指し、Ansibleではなく「Terraform」を採用することにした。「宣言的記述で基盤構成を見える化し、GitHubを用いてそのコードを基盤の開発者、運用者、相互に回していくことで、基盤の開発者と運用者が一体となってDevOpsができる仕組みを選択しました」（船柳氏）

　また基盤の課題を踏まえてシステムを再設計した。基盤をイミュータブルな設計にするために、仮想サーバからKubernetes環境に変更することにし、マネージドサービスの「Google Kubernetes Engine」（GKE）を選択することで、エンジニアが開発に集中できる環境にした。

　ただ、このシステムが通信する対向システムはオンプレミス環境にある。そのため、Google Cloud Platform（GCP）とオンプレミスとをつないだハイブリッドクラウド構成が必要という結論に達した。

　「ここまで来ると、アプリケーションのビルドやデプロイも、従来のように手作業ではなく自動化させたいところです。そこで、内製開発しているCI/CD（継続的インテグレーション／継続的デリバリー）パイプライン『Qmonus Value Stream』を採用することにしました」（船柳氏）

つれない返答に対立するのではなく、腹を割って話し根本的な理由を探る

　「これで俺の考える、最強の基盤構想が出来上がった」――そう考えた船柳氏は意気揚々と社内ITシステム担当のところに赴き、「Kubernetesを使いたいのでGCPを一つ、トッピングでオンプレミス接続をお願いします」とオーダーした。

　ところが返ってきたのは「それはメニューにありません」というつれない返答だった。

　NTT Comでは「社内システムはオンプレミスで構築する」ことが大前提にあったためだ。ITシステム担当者と半年ほど調整を重ねた結果、ようやく社内網に接続できるGCPを払い出す仕組みが完成したが、「コンテナやKubernetesネイティブではなく仮想マシン単位でのリソース払い出し」「ダイレクトではなく、オンプレミスを通ってからインターネットに抜ける」といった制約があり、船柳氏らが作りたい環境とは異なるものだったという。

　そこで船柳氏が取り組んだのは、社内ITシステム部門と対立することではなく、「腹を割って話す」ことだった。すると、「なぜ仕様にないものは提供できないか」の理由が分かってきたという。いくらルールを設けてもヒューマンエラーはどうしても起きる。そのことを前提に、ある程度制約をかけておきたい――環境を提供する立場にある人ならば共感できるという理由があった。

　船柳氏はさらに、社内ITシステム部門が「何を守りたいか」を明確にするためヒアリングを進めた。その中で「オンプレミスにあるシステムのデータをきちんと守ること」「オンプレミスと接続するネットワークの設定は、ITシステム担当で把握しておくこと」の2点が重要だということが分かってきた。

　これを踏まえて船柳氏は、「オンプレミスにあるシステムのデータをきちんと守れるよう、クラウド時代に即したセキュリティ対策を見極め、従来の境界型セキュリティ以上のセキュリティ対策を実施する」「ネットワーク設定に関するITシステム部門の要望を受け入れた上で、迅速にCI/CDを回すという自分たちのやりたいことを実現できる環境を構築、設計していく」という2つの方針を定め、具体的なGCPの設計に落とし込んでいった。

ITシステム部門の要望も受け入れた仕組みを提案し、社内の承認を獲得

　GCPでは、「Virtual Private Cloud（VPC）」というマネージドネットワークのリソースの中に、「サブネット」というリソースを作成できる。そしてサブネットの中にコンピュートを作成するとグローバルIPアドレスとプライベートIPアドレスが付与されるが、「限定公開サブネット」というリソースを作るとグローバルIPアドレスを持たないようにできる仕組みだ。

　船柳氏は当初、ITシステム担当者が制御する限定公開サブネットと通常のサブネットを分割することで、オンプレミスとの直接の通信は防ぎつつ、自分たちのシステムの冗長構成を確保する構成を考えた。だが、GCPから、保護された武装領域（MZ）を経てSMTPでメールシステムにアクセスできるなど、「無防備な通信」が課題になった。

　そこで、VPCを分離することでセキュリティ面でも分割を図ることにした。「この結果、パブリック側のVPCは制約なくGCPを利用できる一方で、限定公開サブネットのコンピュートはルーティング的にもしっかり分離されました。また、プライベートのVPCとパブリックのVPCをVPCピアリングで接続し、お互いのVPCサブネットのみを広告し合うよう設定することで、オンプレミスの環境とパブリックVPCのコンピュートの直接通信ができない仕組みにできました」（船柳氏）

VPC分割のメリット

　さらに、GCP側をプライベートとパブリックに分け、制約のあるプライベートな世界と制約のないパブリックな世界に分割した。前者のプライベート側の設定はITシステム担当が投入し、コントロールする一方で、パブリック側の設定は船柳氏ら基盤担当が投入する仕組みだ。VPC間の通信はFirewall Rulesで縛るとともに、Firewall LogとVPC Flow Logを残すことでセキュリティを確保した。パブリックVPCのコンピュートは、Envoy Proxy経由でオンプレミスのシステムと通信する仕組みだ。

Envoy Proxyを用いた通信の仕組み

　このように、ITシステム部門が求めるレベルのセキュリティを担保できる設計が固まったことから、無事承認を得る運びとなった。

　「社内システム担当と対立しているだけでは話は前進しません。お互いWin-Winの関係を目指し、システム担当が譲れないところはきちっと守った上で構成を提案していきました」（船柳氏）

　しっかり筋が通った内容で「守りたいこと」を担保したことで社内システム担当もきちんと提案に向き合い、基盤の開発者と運用者、システム担当と、三者合同で検証を実施し、「この構成であればセキュリティが担保できる」と判断された。

課題に迫られたときこそ技術的負債解消のチャンス

　だが、これでゴールではなかった。他にも、新システムの構成が社内ポリシーに準拠しているかどうかの承認を得る手続きが残っていたのだ。船柳氏らはセキュリティ担当やITガバナンス担当、ネットワーク担当のところを回って、「一つ一つのポリシーをひもとき、所掌範囲を明確にし、仁義を通してきちんと説明して納得いただくことで社内ポリシーの準拠の承認をいただき、構成を合意させることができました」と述べた。

　こうして社内の各部署からも承認を得た上でハイブリッドクラウド基盤を構築し、無事にマイグレーションを終了したという。

　船柳氏はこの取り組みを経て、「EOLのように対応せざるを得ない課題があるときこそ、技術的負債を解決するチャンスなので前向きに攻めましょう」と述べた。これまで実現したいと思いながらなかなかできなかった、基盤開発者と運用者によるDevOps、限定公開サブネットやVPCサービスコントロールの導入など、クラウド時代に必要な開発、運用の体制を構築したり、セキュリティを見極めたりするチャンスになるという。

　「社内での折衝や説明を通して、社内システム担当とWin-Winになるように技術的問題を解決していきましょう。そして、自分たちがした苦労を次の開発者が繰り返さないよう、課題をうやむやにしたままシステムを作らず、きっちり社内ポリシーとして認めてもらった上で次に残していきましょう」と述べ、同じ目的を持つ仲間や若手、皆が幸せになれるようしっかりコンセンサスを得つつ、次世代につながる土台を作っていくことの大切さを呼びかけ、講演を締めくくった。

特集：クラウドネイティブに「一歩踏み出す」現実的な処方箋-今のスキルで乗りだす秘訣-

素早く価値を生み出すためにビジネスとITサービス開発、運用を直結させる取り組みが不可欠となる中、注目されているアプローチがスピーディーにアプリケーション＝ビジネスをデプロイし、その後も高度な変化適応力を持ちながら、安定的に運用する「クラウドネイティブ」だ。だがクラウドネイティブの実践に当たっては、コンテナ、オーケストレーション、マイクロサービスアーキテクチャなどの開発、運用技術の知識が不可欠で、人材も予算も不足する企業で全てを実践するのは難しい。本特集では、クラウドネイティブの実践に向けてどのような取り組みを進めていくべきか指南する。

特集：クラウドネイティブに「一歩踏み出す」現実的な処方箋-今のスキルで乗りだす秘訣-