- 目次
1. オンプレミス型のシステムはモダナイゼーションの波に乗れるのか
クラウド全盛の時代となった昨今、オンプレミス型のシステムは時代遅れのレッテルを貼られがちです。しかし、近い将来でオンプレミス型のシステムがすべてクラウドに単純に置き換えられるということは無いでしょう。少なくとも現時点では、オンプレミスはクラウドに対して、セキュリティ面やカスタマイズ性においてアドバンテージがあるからです。そのため、双方の利点を活せるハイブリッドクラウド型のシステムも増えていくでしょう。
クラウド環境においては構築・運用が高度に自動化されているケースがほとんどですが、残念ながらオンプレミスの世界がモダナイゼーションの波に乗り遅れてしまった感は拭えません。オンプレミスのシステムを多数構築・運用しているNTTデータでは、古くからAnsible、Puppetといったオンプレミスの世界でも適用できる構築自動化ツールをしばしば活用してきました。しかし、自動化成熟度の観点でクラウド環境のそれと比較すると、どうしても見劣りしてしまう面があります。そのため、さらに高度な自動化を目指す人々はクラウドネイティブに移り、オンプレミスの世界から去っていきました。オンプレミス型のシステムは、このまま時代に取り残されていってしまうのでしょうか？
2. オンプレミス型のシステムにおける自動化の取り組み
Ansible、PuppetはIaC（Infrastructure as a Code）で用いられるツールの代表格です。前述の通り、NTTデータにおいてもAnsible、Puppetなどのツールを用いてオンプレミス型システムの構築・運用の自動化に取り組んでおり、一定の効果をあげてきました。
しかし多くのプロジェクトが初期構築にフォーカスし基盤を自動化した結果、いくつかの問題点が見えてきました。
- （1）ある程度大きな規模でないと費用対効果が出難い
- （2）初期リリース後の自動化コード保守
- （3）パラメーターシートと自動化コードの高い壁
（1）について、基盤自動化は手作業での構築と比較し、一般的にはイニシャルコストが大きくなる傾向にあります。基盤自動化は、「開発したコードを使いまわしできる」、「同じ構成のサーバを多数構築する」ことを得意としており、大きな効果を発揮します。そのため、規模が小さいシステムや、少数多品種な構成のシステムには向いていません。ただし維持保守フェーズでも自動化コードを利用し続けることで、“見かけ上の適用台数”を増やして大きな効果を得ることができます。
図1：基盤自動化導入効果の考え方
（2）について、システムが維持保守フェーズに入った後、コードを開発した開発者がプロジェクトを去っているため、誰もコードを触れなくなってしまったケースがしばしば発生します。システムの変更に追従できなくなり、開発したコードが使われなくなってしまっては、イニシャルコストが無駄になってしまいます。IaCにおいては、維持保守フェーズまでを意識して考えた設計をするのが大事なポイントです。
（3）について、設計ドキュメントのフォーマットはお客様からの指定があることもありますが、パラメーターシートも例外ではありません。IaCでは、パラメーター情報をYAMLなどのツールが理解できる形式で記述する必要がありますが、これを人手で転記するとヒューマンエラーが入る余地があり、品質を損ねる恐れがあります。そのため、NTTデータではExcelのパラメーターシートからYAMLにコンバートするツールを開発して対応するケースが時々ありました。
3. “継続的にリリース”はアプリケーション開発だけのものではない
従来の自動化の取り組みは、人手で実施する作業をIaCツールで代替して、構築速度、効率、品質を向上させるのを目的としていました。ですがこのアプローチでは、クラウド環境におけるアプリケーションと基盤を包括した高度な自動化から見ると自動化範囲が限定的です。
しかし、オンプレミス型のシステムにおいても“インフラCI/CD”を導入すれば、最先端の自動化レベル実現を目指すことができます。“インフラCI/CD”を導入してオンプレミスの基盤を自動化コードのモジュールで抽象化し、アプリケーションのライブラリ同様の感覚で利用できるようにすれば、“簡単なコード”を記述するだけでオンプレミス型のシステムを構築、維持保守することが可能になります。このコードならびにパラメーター情報のYAMLファイルを正としてGitリポジトリで構成管理することで、従来困難だったアプリケーション開発と同レベルのバージョン管理を実現できます。さらにGitリポジトリへのコミットをトリガーとしてAnsibleやServerspecを実行することで、まさにアプリケーション開発と同等のCI/CDを基盤構築の世界で実現することが可能になります。
さらにインフラCI/CDの発展形として、クラウドネイティブな環境で人気がでてきた“GitOps”があります。システム基盤のパラメーターを変更する場合、基盤チームとスケジュール調整して、手順書を作成して、パラメーターのレビューを受ける…など、さまざまな手順が必要となります。手順の実施に時間を要してしまい、気軽にパラメーター変更ができない運用体制になっていることも多いでしょう。これらの問題はGitOpsで解決できます。
GitOpsを提唱したWeaveworks社はGitOpsを「宣言型インフラストラクチャとアプリケーションの信頼できる唯一の情報源としてGitを使用する」と定義しています。インターネットに接続できないケースが多いオンプレミス環境では、スタンドアロンで使えるGitLabがGitリポジトリとして使いやすいでしょう。GitLab社ではGitLabのツール特性に合わせてGitOpsを以下のように定義しています。
GitOps ＝ IaC（基盤自動化）＋ MRs（マージリクエスト）＋ CI/CD
パラメーター情報を含む基盤の自動化コードを開発用ブランチにコミット、リリース用ブランチにGitLabのマージリクエストを出します。このリクエストを受けた承認者は内容をレビューし、問題が無ければリリース用ブランチにコミットします。するとリリース用ブランチへの変更をトリガーにインフラCI/CDの仕組みが動作し、変更が反映されます。そしてこのフローは継続的に実行されます。
つまり今までExcelなどの管理簿で管理されてきたものが、Webベースでリアルタイムな管理ツールに置き換えられ、かつ承認と同時に変更が自動反映されるため、今までのような基盤チームとの要員調整なども不要になります。これは基盤の変更反映へのハードルを大きく下げ、また反映までのリードタイムを大幅に削減するのにも効果があるプラクティスです。
図2：GitOpsを実践した基盤自動化の概要
4. まとめ
高度にコード化されているクラウドネイティブの世界だとGitOpsの実現は容易です。ですが先に述べた通りオンプレミス型システムでは基盤を抽象化する部分を開発する必要があり、GitOps導入の高いハードルとなっています。
しかし、NTTデータは多くのオンプレミス型システムで基盤自動化を進めています。また、一部のシステムではGitOpsのプラクティス適用に向けた整備も始まっています。適用範囲を絞ってスモールスタートするケースがほとんどですが、最初の一歩を踏み出すことに大きな意義があります。
将来的にGitOpsをオンプレミスの世界で完全に実現できれば、ニューノーマル時代にふさわしいモダンなオンプレミス型システムと言えるのではないでしょうか。その実現に向け、NTTデータはオンプレミス型システムのモダナイゼーションを推進していきます。
