クラウドネイティブなアプリケーションの開発と運用を支えるCI/CD導入の勘所（後編）
クラウドネイティブNow

クラウドネイティブなアプリケーションの開発や運用において重要な要となるCI/CD（継続的インテグレーション / 継続的デリバリー）。近年ニーズが高まっているDX（デジタルトランスフォーメーション）における特徴の1つにアジャイル開発があり、その実現手段としてDevOpsが普及し、そのためのツールとしてCI/CDが注目を集めています。
しかし、CI/CDの運用が展開できている企業はまだまだ少なく進んでいないのが実情です。当社でもCI/CDに関するご相談は増加していますが、運用までの展開を検討しているお客様の数はまだ限られています。
本特集では、このCI/CDの運用への展開における課題と勘所について、前編では従来型システムとDXシステムにおける差異を中心にCI/CDの現実を解説し、後編ではCI/CDの運用への展開における課題と勘所を解説します。

セキュリティ上の理由による分離における課題の勘所

前編でCI/CDに対する障壁とは開発と運用のセキュリティ分離と環境の差異と解説しました。では、セキュリティ上の理由による分離とは具体的にどのようなことでしょうか。
多くの企業や組織では、開発と運用を分離しています。これは、機能を納期どおりに提供することが目標の「開発」と、安定した運用環境の維持が目標の「運用」という目標の異なる部門を分離することで、セキュリティを確保し安定運用を図るためです。
また、国内の特に金融業界などでは日本版SOX法により、同様に開発と運用を分離することが示されています。分離について詳しく見ていきましょう。

ここでの分離には、職務・職責の分離、環境の分離、アクセスの分離があります。職務・職責の分離は、開発者と運用者というように職務や職責が分離していることを意味しています。環境の分離、アクセスの分離は、開発環境と運用環境そのものや、その環境へのアクセス権限が分離していることを意味しています。
こういったセキュリティ上の理由による分離から、開発者は、開発資産を開発環境にあるCIツールから運用環境に直接リリースできなくなっています。
また、日本企業の風土には「失敗が許されない」という考えが根底にあり「失敗したら巻き戻す」という考え方は馴染みが薄いこともあります。このような風土ですと失敗しないためのセキュリティ重視や責任範囲の分断が強くなります。
さらに、日本ではユーザー企業とITベンダーが別組織である割合が高く、独立行政法人情報処理推進機構（IPA）の調べによると80%程度と言われており、対して米国では同組織である割合が80%程度と言われています。こうなると開発資産を開発環境のCIツールから運用環境にリリースするのは難しいと言わざるを得ません。

では、なぜ開発と運用をセキュリティ上で分離する必要があるのでしょうか？
開発者の目標は機能を納期どおりに提供すること、運用者の目標は安定した運用環境の維持です。すると、開発者と運用者の間で、適用手順、リリースタイミング、運用設計という観点でそれぞれ実現したいことが以下の表にまとめたように変わってきます。

では、どうしたら良いのでしょうか？これらの違いを踏まえ、課題の解決に向けた勘所は「GitOpsによる開発資産の運用環境への安全なリリース」を実現することです。GitOpsは2017年にWeaveworks社のブログ内で紹介され、Gitを軸として開発資産と運用資産の両方を管理するためのCI/CDの手法です。GitOpsを適用することで、開発者と運用者の間で、適用手順、リリースタイミング、運用設計のそれぞれを以下の表にまとめたように共通化することができます。どういうことなのか？それぞれ一つずつ見ていきます。

まず、適用手順に対する勘所は「開発と運用で齟齬（そご）のないやりとりを実現すること」です。そのキーワードとなるのが「Infrastructure as Code（IaC）」です。これは、開発と運用の間で認識の齟齬が発生する手順書のやりとりをコード化して共通言語化するものです。具体的にはコンテナ技術を用いてソフトウェアスタックをコード化し、AnsibleやHELMといった構成管理ツールでインフラの構成をコード化します。そのうえで開発環境やステージング環境、本番環境に展開していきます。これにより、開発と運用で齟齬のないやりとりを実現できます。

次に、リリースタイミングについての勘所は「安全かつ迅速なリリースを実現すること」です。具体的にはアプリソースとIaCのリポジトリを分離し、マージリクエスト承認を経てCI/CDを実施します。ここで、開発者にアプリソースのリポジトリ、運用者にIaCのリポジトリにおける操作権限を付与し権限を分離することで開発と運用の分離を実現できます。また、マージリクエストで承認されることにより、品質確保済みの開発・運用資産を安全にリリースすることができます。さらに、運用環境からプルによるIaCリポジトリを監視することで、IaCリポジトリ変更を検知、本番環境へ展開して本番環境の状態を常に管理できます。これらを活用することで、安全かつ迅速なリリースを実現できます。

最後に、運用設計に対する勘所は「異常監視・リカバリーを実現すること」です。ここではその手法を3つ紹介します。

• ローリングアップデート
  旧版のアプリインスタンスを新版のアプリインスタンスで徐々に置き換える手法で、途中で異常を検出すると、全てのインスタンスを旧版にロールバックすることで、アップデートの適用漏れ等を防ぐことができます。

• Blue-Green Deployment
  旧版と新版のアプリインスタンスを同時に稼働させ、問題なければ新版へ切り替える手法で、問題を検出した時は、稼働中の旧版へ安全に切り戻すことができます。

• カナリアリリース
  旧版と新版のアプリインスタンスを同時に稼働し、新版へトラフィックを徐々に切り替える手法で、Blue-Green Deploymentと同様に、問題の検出時は旧版へ安全に切り戻すことができます。

これらの手法でインスタンスを置き換え、異常を監視し、異常があればリカバリーという手順を実現できます。以上が、セキュリティ上の理由による分離という課題解決の勘所です。

運用環境の違いにおける課題の勘所

続いて運用環境との違いという課題です。これにはまず、開発した資産が環境に依存していることで、そのままでは本番環境に展開できないという問題があります。そのような問題が発生する理由には、例えば次のようなことが挙げられます。

• コードベースの不一致
  緊急修正を本番環境にのみ実施してしまいコードベースが不一致となってしまう

• 環境に依存した定義の管理が煩雑
  外出しした環境に依存する設定の管理方法が定まっていないために定義が膨大となり管理が煩雑となってしまう

• ツールバージョンの不整合
  環境によって利用するツールのバージョンが異なるために不整合が生じてしまう

このような問題を解決するための勘所は「開発資産の環境依存を排除し、いつでもリリースできる状態にする」ことです。どういうことか？順を追って説明します。

コードベースの不一致

コードベースの不一致についての勘所は、コードベースを開発環境と本番環境で統一することです。たとえば、本番環境で問題が発生し、緊急対処のために本番環境のソースコードを修正する場合、その修正を開発環境にフィードバックできていないと、フィードバックがされていないまま開発されてしまいます。それにより、開発資産を本番環境に展開するために、ソースコードに本番環境用の修正を加える必要が発生してしまいます。
これに対し、コードベースを統一することでこのような状態になることを防ぎます。もし、環境間でコードベースを一本化できない場合は、Gitリポジトリを同期することで対処します。

環境に依存した定義の管理が煩雑

環境に依存した定義の管理が煩雑になることについての勘所は、一括管理ツールとGitを用いて定義を容易に管理することです。
環境に依存する定義とは、たとえばデータベースへのログイン情報であるユーザー名やパスワード、アプリケーションのアクセス先URLやアクセストークンなどがあります。このような定義情報はシステムの規模に応じて膨大になることが多く定義の管理が煩雑になります。また、環境ごとに定義変更を適用する手順が必要なため、ヒューマンエラーによる適用ミスを誘発しやすいという問題があります。
それに対し、勘所では一括管理ツールを用いて膨大な定義情報を管理し、一括管理した情報ごとにGitで管理します。一括管理ツールは、パスワードやアクセストークンといった秘密情報はVaultを、秘密情報以外はHELMなどを使うといったように定義の種類に応じて選定します。
また、一括管理ツールを使うことでGitによって管理された定義に沿って自動的に展開されるため、適用ミスを防ぐことができます。

ツールバージョンの不整合

ツールバージョンの不整合についての勘所は、コンテナを活用してツールのバージョンを揃えることです。
たとえば開発をしていて、環境にもともとあったツールのバージョンを変更することがあります。その場合、バージョンの変更が開発環境のみだと、本番環境で意図しない挙動に繋がります。それを防ぐために、コンテナ技術を活用します。
具体的にはツールをコンテナに同梱して依存関係をDockerfileに明示的に宣言することで、開発環境と本番環境といった環境の違いに左右されず、ツールのバージョンを揃えることができます。この際、ツールの依存ライブラリーや設定ファイルなど、他にも同梱するものの選定が必要です。

まとめ

DevOpsが主流になってくると、他人が作成したプログラムやCI/CD、コンテナに潜む脆弱性を防ぐという課題が重要になってきます。そこでDevOpsにセキュリティを一体化させたDevSecOpsが登場しています。このDevSecOpsではCI/CDが重要となるため、これらの勘所を活用して頂ければ幸いです。
クラウドネイティブなアプリケーション開発を支えるCI/CDの導入でお困りのお客様は当社にご相談ください。

関連製品・サービス

当社が提供するDX実現の課題にお応えするハイブリットITサービスの詳細は下記ページをご覧ください。

• FUJITSU Hybrid IT Service