Infrastructure as Codeを実践したインフラ運用高度化のアプローチ　～キンドリルジャパンが取り組むプロジェクト事例から

Text＝竹屋 正樹　キンドリルジャパン

インフラ運用高度化を目指した
Infrastructure as Codeの適用　

データセンター内で完結するシステム環境から、複数のクラウドサービスを組み合わせて業務システムを提供する形態への変遷により、エンタープライズ企業のインフラ運用業務が日々複雑化している。

安定稼働を重視してリスクを回避する従来のSoR（System of Record）とは異なり、ある程度のリスクを許容してスピードを重視するSoE（System of Engagement）では、顧客から求められるビジネス目標に対して、いかにデジタルテクノロジーを駆使して変革を推進していくかが鍵となる。

すなわち、インフラ運用のプロフェッショナルであるキンドリルジャパンは、「守りのIT」であるSoRの概念と「攻めのIT」であるSoEの概念をバランスよく取り入れたエンタープライズレディな領域を模索しなければならない。

SoEの概念で重要視される迅速性・効率性を実現する上で検討されたアプローチが、ソフトウェア開発のプラクティスをインフラ運用管理に取り込むInfrastructure as Codeである。

一般には「Infrastructure as Code = 自動化」と単純に置き換えられる傾向にあるが、コード化によって得られるメリットは自動化のほかにも、ソフトウェア開発の現場で培われた各種プラクティス（自動テスト、CI/CD、バージョン管理など）を適用できる点が着目されている。

Infrastructure as Codeの適用により、従来手動で実施していた各種作業や設定が、システムの状態をコードで自動的に管理するアプローチへと大きく変化し、人的ミスの削減や管理不整合の排除、構成変更の迅速化といった効果を享受できる。

以下に、キンドリルジャパンが取り組んだインフラ運用高度化の事例を紹介しよう。

プロジェクト事例にみるインフラ運用高度化

自動化事例①
Terraform／Chefを活用したプロビジョニング自動化

最初に紹介する事例は、インフラ運用業務としてインスタンス（本事例では仮想サーバーを指す）の払い出しを自動化するクラウド基盤プロジェクトである。

案件発足時は、Infrastructure as Codeのアプローチとしてさまざまなプラットフォームに適用できるChefを採用したプロビジョニング自動化に取り掛かっていたが、Chefの実行タイミングはOS起動後となるため、スクラッチからインスタンスを作成する用途には適さなかった（2022年現在、あらためてInfrastructure as Codeツールの優位性を比較し、コードの公開件数や初期学習の容易性からChefをAnsibleに置き換えるプロジェクトが進行中である）。

そこで本格的に採用したのが、Terraformである。Terraformはパブリック／プライベートの多彩なクラウドリソースに特化した処理をテンプレートに記述・実行し、インスタンスの作成からより複雑なシステム構築を自動化できるInfrastructure as Codeツールである。

図表2に示すInfrastructure as Codeを適用したクラウド基盤では、以下の機能を提供している。

・マルチプラットフォームのクラウド基盤に対して、UIから標準化されたインスタンス（複数のOS・ミドルウェアの組み合わせ）を自動的に払い出す。

・ネットワークやストレージはSoftware Defined環境として実装する。

・Terraform Template／Chef Cookbookは、バージョン管理ツールであるGitLabに一元管理する。

クラウド基盤でのインスタンスの払い出し方法を、図表3に示す。

本事例では、キンドリルがグローバル・プログラムで提供するCACF（Cloud Automation Community Framework）上で稼働しているAnsible TowerのUIを活用して、インフラ運用担当者がインスタンスを払い出している。

払い出されたインスタンスはAnsible Tower上で管理されており、利用期限を過ぎたリソースをAnsible Tower上から自動で破棄するようなインフラ運用を実現している。

パターン化されたインスタンスに応じてAnsible Towerのジョブテンプレートを用意し、Ansible Towerから追加変数として必要なパラメータ（CPU／MEM値やディスク容量など）を入力することで、Terraformを経由して各種インスタンスの構成をクラウド基盤上に自動的に払い出す。

OS起動後の環境構築やミドルウェアの導入・カスタマイズは、Terraformから呼び出されたChefが担っている。

・ Terraformが実行エンジンとなり、テンプレートに書かれた処理内容を指定先のクラウド基盤へAPIコールして処理を実行する。

・最初の指示で、仮想サーバーのインスタンスを払い出す。

・ OSの環境設定、ミドルウェアの導入・カスタマイズはTerraformのテンプレートからChefクライアント経由で、実行リスト（run list）に基づいたCookbook （Recipe）を実行する。

なお2022年現在、インスタンスの払い出し対象はOSとしてAIX／Red Hat Enterprise Linux （RHEL）／Windows、ミドルウェアとしてWAS／Db2／IIS／SQL Serverであり、各種製品のバージョンアップに応じて定期的にプラットフォームの幅を広げている。

自動化事例②
CI/CDパイプラインを適用したコード運用の自動化　

インフラ運用自動化の最初のステップであるプロビジョニング自動化が本番稼働を迎えた後、次のステップとしてChefのCookbookをはじめとするインフラコードの開発・リリースサイクルを高速化する試みとして、CI/CDパイプラインによるコード運用自動化の検討を開始した。

一般的なCI/CDの定義に対し、今回の案件で適用したインフラCI/CDの定義は、図表4のとおりである。

上記の実装内容に基づき、すでにユーザー環境で利用されていたソースコードのバージョン管理ツールであるGitLabと親和性のあるGitLab-RunnerをCI/CDパイプラインの中核として配置し、開発したインフラコードをPushした際に、構文規約や検品作業も含めて自動化を推進した。

本事例で実装したインフラCI/CDパイプラインの概要図を、図表5に示す。

改修したインフラコードを検証環境のGitLabにアップロードすることで、CIツールであるGitLab-Runnerが自動で検知してCI/CDパイプラインが実行される。

CI/CDパイプラインに組み込んだジョブは順次実行（場所により並列実行）され、すべて正常終了と表示されれば、本番環境のGitLabにリリースされる。

インフラコードをGitLabリポジトリで管理することで、第三者が環境変更作業前に、コードで作業実施前後の差分を客観的にレビューすることが可能となり、インフラ運用での人的ミス混入が最小化された。

それに加えて、GitLab上でTerraform Template／Chef Cookbookの開発・管理を行い、インスタンスの払い出しからインフラコードのテストまでを自動的に実行可能にしたことで、インフラコードの改修に要する運用フローのリードタイムを大幅に改善できた。

自動化事例③
ITSM／Ansibleを連携したサービス・リクエスト自動化　

CI/CDパイプラインによるコード運用の自動化が実現した次のステップとして、自動化2.0への飛躍を目指し、サービス・カタログで管理されたインフラ運用業務のEnd-to-Endの自動化に着手した。

クラウド基盤で管理されたインスタンスに対する運用作業は、すべてITSM上のサービス・カタログで管理されており、イベントやサービス・リクエストなどの各種IT管理プロセスと連携することで、サービス・カタログの依頼からインフラ運用作業までの間に人が介在することなく、完全自動化が可能となる。

本案件では、ITSMリクエスト・ワークフローと自動化プラットフォームであるCACFをAPIで連携している。

連携方式には大きく分けてPush型とPull型が存在するが、機能のトリガーを独立させることが可能であり、開発段階で機能的な問題が生じた場合に問題箇所の絞り込みが容易となるPull型を選択した。

クラウド基盤上のサービス・リクエスト作業で依頼頻度の高いDBレコードの自動取得を一例に、ITSMリクエスト・ワークフローとAPIの連携ポイントを以下に示す。

・エンドユーザーの依頼とは別に、一定間隔でCACFからITSM APIに対してPlaybook（uriモジュール）を実行することで、JSON形式のリクエストファイルを取得する。

・ITSMリクエストのステータス更新用のAPIを開発し、処理状況を都度POSTして更新することで、エンドユーザーが理解しやすい実装とする。

・機微情報を含むSQLファイルを想定し、ITSMリクエストフォームに暗号化したパスワード情報を記載する欄を追加する。

・CACFから複数サーバーに対してPlaybookを実行できるようにWorkflow Templateを用意し、処理結果に応じて専用のTeamsチャネルにメッセージを通知する。

本案件では汎用的な作業を自動化したアーキテクチャを実装したため、さまざまなサービス・リクエストやプラットフォーム（AWS、Azure、GCPなど）への横展開が可能である。

一例として、事例①で紹介したプロビジョニング自動化も、ITSMとCACFをAPI連携させることで、人手を介することなくエンドユーザーの依頼に基づいて、自動でインスタンスを払い出すことができる。

インフラ運用高度化を目指して得た知見　

本稿では、プロジェクト事例をもとに過去数年に渡るインフラ運用自動化の取り組みを紹介したが、Infrastructure as Codeを適用した運用高度化により、今まで検討されていなかった自動化固有の課題を発見できた。

・クラウドが普及した世界での製品／サービスのライフサイクルは、すでに数カ月に1度のペースでバージョン／リリースアップを繰り返しているため、インフラ運用自動化の世界でもソフトウェア開発時と同様に高い互換性の保証が求められることになる。

・自動化ツールの導入は目的ではなく手段であり、インフラ運用高度化に銀の弾丸は存在しない。時には状況に応じて従来の運用体制・プロセスを変更することを念頭に置きながら、最適な自動化ツールを選定する必要がある。

・最初から完全自動化を目指すのではなく、小さな作業から自動化を進めることが重要となる。今後はアカウント内でコード開発を担う人材を増やし、使用する人自身がコードを改修するコミュニティモデルに転換する必要がある。

インフラ運用のプロフェッショナルである我々キンドリルは、SoRが主流だった従来のITインフラに対して、いかにSoEを適用していくかがユーザーから求められる期待値となる。

本稿で紹介したプロジェクト事例がインフラ運用高度化の理解を深める一助となれば幸いである。