text：
竹屋 正樹 キンドリルジャパン
小栗 直樹 日本IBMシステムズ・エンジニアリング（2021年6月より日本IBMへ出向中）
本稿では、筆者らが参画したInfrastructure as Codeの概念を取り入れたクラウド基盤構築プロジェクト、およびTerraformとChefを活用したシステム構築の自動化、そしてIT Service Management（以下、ITSM）リクエスト・ワークフローとAnsibleを活用した運用業務の自動化の各事例を紹介する。
DXの実現と構築・運用の自動化
企業を取り巻く環境の変化
本題に入る前に、今回の構築・運用自動化に取り組むきっかけとなったデジタル・トランスフォーメーション（DX）について、簡単に紹介する。
DXとは、「ITの浸透を通じて人々の生活をよりよく変える」概念として、2004年にスウェーデンのウメオ大学（Umea University）のエリック・ストルターマン（Erik Stolterman）が「Information Technology and The Good Life」で提唱したものとされている。
日本では、経済産業省が2018年発表の「DXレポート」で、IDC JapanのDX定義（*1）を参考にDXのスピーディな推進の必要性を説き、2019年にはDX推進のための定性的・定量的指標をまとめた「DX推進指標」（デジタル経営改革のための評価指標）を公開している。
「DX推進指標」では、企業はクラウドなどの新たなプラットフォームを利用した新しいビジネスモデルを通じて、競争上の優位性を確立することが求められている、と指摘している。
一方、クラウド利用を促進する団体「CNCF（Cloud Native Computing Foundation）」では、コンテナ技術の推進とテクノロジー業界の足並みを揃えるために「Cloud Native Trail Map」を公開し、DX推進を技術面からリードしている。
上記の内容から、DXの実現にはクラウドネイティブの要素をエンタープライズ・システムに取り入れることが、今後の重要なファクターとなることを押さえておきたい。
*1 IDC JapanのDX定義
「企業が外部エコシステム（顧客、市場）の破壊的な変化に対応しつつ、内部エコシステム（組織、文化、従業員）の変革を牽引しながら、第3のプラットフォーム（クラウド、モビリティ、ビッグデータ／アナリティクス、ソーシャル技術）を利用し、新しい製品やサービス、新しいビジネスモデルを通して、ネットとリアルの両面での顧客エクスペリエンス（経験、体験）の変革を図ることで価値を創出し、競争上の優位性を確立すること」
クラウドネイティブに求められる業務上の価値
インフラの運用では、堅牢なIT基盤を維持していくためのSoR（System of Record）と、顧客との繋がりを強く意識したSoE（System of Engagement）の2種類の考え方が存在する。
今後クラウドネイティブを推進していくうえでは、いわゆる「守りのIT」であるSoRの概念に「攻めのIT」であるSoEの概念を取り入れていくことが必要となる。
SoEでは、顧客が掲げるビジネス目標に対して、デジタルテクノロジーをいかに駆使して実現するかが鍵となるが、そのなかでクラウドネイティブの推進によって実現する価値はSoEの中核に位置づけられる。
クラウドネイティブを目指した
Infrastructure as Codeの実装
前述したSoEで重要な柔軟性、拡張性、迅速性などの実現に向けた新しいアプローチが、ソフトウェア開発のプラクティス（実践）をインフラの運用管理に取り込むInfrastructure as Codeである。
一般には「Infrastructure as Code＝自動化」と、単純に置き換えられる傾向にあるが、コード化によって得られるメリットとしては自動化のほかにも、ソフトウェア開発の現場で培われた各種プラクティスを適用できる点が着目されている。
Infrastructure as Codeの適用により、従来手動で実施していた各種作業や設定が、システムの状態をコードで自動的に管理するアプローチへと大きく変化し、人的ミスの削減や管理不整合の排除、構成変更の迅速化といった効果を享受できる。
キンドリルが担うインフラ運用の自動化
企業がアウトソーシングを導入する理由
一般に企業がアウトソーシングを導入する主な理由として、本来の経営に集中するために外部から専門技術やノウハウを調達し、業務の効率化によりコスト削減やスピード化を実現することが挙げられる。
◎アウトソーシングのメリット
・自社にない専門的な技術・ノウハウの活用
・人件費およびそのほかのコストの削減
・業務の効率化・スピード化
・人手不足への対応
・設備投資の削減
・コア業務（得意な分野）への経営資源の集中
一方、キンドリルが担うインフラ運用は戦略的アウトソーシング（Strategic Outsourcing）では、上記の目的に加え、ITの最新技術を駆使するとともに、蓄積してきた運用実績による高品質・安定的な運用を実現し、コスト最適化を促進・持続することが最大の特徴と言える。
筆者らが参画した案件でも、DX推進のためにカスタマーファーストなIT技術を活用し、アジャイルなオペレーションモデルを目指すとともに、堅牢かつ必要十分なITインフラを提供することを目標として掲げている。
アウトソーシングで求められる自動化の適用範囲
アウトソーシング案件では、ユーザーから重要な業務を委託される関係上、明確なKPI（重要業績評価指標）が設けられる。
インフラ運用の場でも、以下のように業務の中断が生じないようシステム稼働率が厳密に定められているほか、日々の運用プロセスでも明確なリードタイムが設けられている。
◎キンドリルが担うインフラ運用基準例
明文化されたSLAの定義と保証
・業務の重要度に応じた高いシステム稼働率（年間の許容ダウンタイム：XX時間以内）
・各種運用サービスのリードタイム
・KPIの設定と評価
徹底したコスト削減
・運用プロセス最適化の常時検討と見直し
・ハードウェア、ソフトウェア、サービスの集約と淘汰
厳密なITセキュリティ遵守対応
・OS、ミドルウェアごとのセキュリティ・ポリシー適用
・数カ月ごとのPDCA実施
また一言で自動化といっても、その対象はシステム構築の自動化にとどまらず、インフラ運用業務のすべてが運用最適化の観点では自動化の対象であり、また運用改善の対象となる。
◎インフラ運用における自動化の適用範囲
サーバー、OS、ミドルウェアの環境構築だけが自動化の対象ではない
・リリース後の環境変更作業の自動化
・インフラコード改修後のテスト自動化
・定期的な稼働確認テスト（ガバナンス観点の設定確認、セキュリティのヘルスチェックも含む）
日々発生する運用業務のすべてが自動化の対象
・各種運用申請のワークフロー化
・払い出したカタログ・サービスの検収・受け入れ作業の自動化
・定型レポート作成・通知の自動化
・システム運用監視の自動化（システムの性能負荷・障害発生時の報告など）
・リリース運用の自動化
・システム増強の自動化、など
プロジェクト事例にみる構築・運用業務の自動化
自動化事例①
Terraform／Chefを活用したクラウド基盤アーキテクチャ
まず紹介する事例は、インフラ運用業務として仮想サーバーの払い出しを自動化するクラウド基盤構築プロジェクトである。
もともとはInfrastructure as Codeのアプローチとして、さまざまなプラットフォームに適用できるChefを採用することで構築業務の自動化に取りかかっていたが、Chefの実行タイミングはOS起動後となることから、スクラッチから仮想サーバーを作成する用途には適していなかった。
そこで本格的に採用したのが、Terraformである。Terraformはパブリック／プライベートのさまざまなクラウドリソースに特化した処理をテンプレートに記述・実行するツールであり、仮想サーバーの作成からより複雑なシステム構築を自動化できる。
本事例では、Terraformを中核とした製品として「Cloud Automation Manager」（現在は「IBM Cloud Pak for Multicloud Management」に統合）を採用した。
本番稼働したクラウド基盤では、以下の機能を提供している。
・マルチ・プラットフォームのクラウド基盤に対して、ポータルから標準化された仮想サーバー（OS、ミドルウェアの組み合わせ）を自動的に払い出す。
・ネットワークやストレージは、Software Defined環境として実装する。
クラウド基盤での仮想サーバーの払い出し方法を図表3に示す。
ここでは当時、IBMがKubernetesのコンテナ管理基盤として提供していた「IBM Cloud Private」（以下、ICP）上で稼働する「Cloud Automation Manager」（以下、CAM）のUIを使用して、インフラ運用担当者がインスタンス（今回の事例では仮想サーバー）を払い出している。
UIからインスタンスの払い出しに必要なパラメータを入力することで、カタログに登録された各種仮想サーバーの構成をプライベート・クラウド基盤上に自動的に払い出す。OS起動後の環境構築やミドルウェアの導入・カスタマイズは、Terraformから呼び出されたChefが担っている。
払い出した仮想サーバーはインスタンスとしてCAM上で管理され、利用期限を過ぎたらリソースを破棄するようなインフラ運用を実現している。
CAMの内部コンポーネントであるTerraformを使用したインスタンスを払い出す処理の流れは、以下のとおりである。
（1）Terraformが実行エンジンとなり、テンプレートに書かれた処理内容を指定先のクラウド基盤への指示（多くの場合、WebサービスなどのAPI呼び出し）に変換して、処理を実行する
（2）最初の指示で、仮想サーバーのインスタンスを払い出す
（3）OSの環境設定およびミドルウェアの導入・カスタマイズは、TerraformのテンプレートからChefクライアント経由で、実行リスト（run list）に基づいたCookbook（Recipe）を実行する（図表4）
なお、インスタンスの払い出し対象はAIX、Red Hat Enterprise Linux（RHEL）、Windows OSと複数のプラットフォームにわたる。
各種OSおよびミドルウェアの導入・カスタマイズの払い出しを自動化したことで、最短でも数日を要していた払い出し申請から引き渡しのリードタイムが、数十分から1時間強までに短縮できた。
自動化事例②
CI／CDパイプラインによるコード運用の自動化
インフラ運用自動化の最初のステップである仮想サーバーの払い出し運用の自動化が本番稼働を迎えた後、次のステップではChefのCookbookをはじめとするインフラコードの開発・リリースサイクルを迅速化する試みとして、CI／CDパイプラインによるコード運用自動化の検討を開始した。
一般的なCI／CDの定義に対し、今回の案件で適用したインフラCI／CDの定義は以下のとおりである。
◎CI（Continuous Integration、継続的インテグレーション）
案件での定義
不具合の早期発見と手戻り削減を目的に、インフラコードのテストを短期間で頻繁に実施する開発手法
案件での実装
GitLabにインフラコードをPushし、自動でテストを実行する
◎CD（Continuous Delivery、継続的デリバリー）
案件での定義
CIによってテストされたコードのマージを自動的に行い、本番環境にデプロイが可能な状態を整える開発手法
案件での実装
GitLabでPull Request を承認し、本番環境にインフラコードを自動でデプロイする
上記の実装内容に基づき、GitLabと親和性のあるGitLab-RunnerをCI／CDパイプラインの中核として配置し、開発したインフラコードをPushした際に構文規約や検品作業も含めて自動化を実現した。
インフラコードをGitLabリポジトリで管理することで、第三者が環境変更作業前に、コードで作業実施前後の差分を客観的にレビューすることが可能となり、インフラ運用での人的ミス混入が最小化された。
GitLab上でChef Cookbookの開発・管理を行い、Terraformで仮想サーバーの払い出しからインフラコードのテストまでを自動的に実行可能にしたことで、インフラコードの改修に要する運用フローのリードタイムを大幅に改善できた。
自動化事例③
ITSMリクエスト・ワークフローとAnsible Towerを連携した運用業務の自動化
従来の手動を前提とした運用業務を回避するために、スクリプトやChef／Ansibleを使用した自動化事例は数多く存在しているが、製品や作業内容ごとに異なる自動化ツールの使用による以下のような自動化1.0の課題も、数多く発生している（図表7）。
・自動化処理が製品や作業内容ごとにブラックボックス化され、ナレッジ展開やスキルセットを標準化できない
・部分ごとの自動化により、エンドユーザーの依頼を元にしたEnd to Endの自動化が実装できない
本案件では、CI／CDパイプラインによるコード運用の自動化が実現した次のステップとして、自動化2.0に飛躍させるため、サービス・カタログで管理された運用業務の自動化に着目した。
クラウド基盤で管理されたインスタンスに対する運用作業はすべて、ITSM上のサービス・カタログで管理されており、イベントやサービス・リクエストなどの各種IT管理プロセスと連携できる自動化プラットフォームを選定する必要がある。
そこで採用したのが、CACF（Cloud Automation Community Framework）である。
キンドリルがサービスとして提供しているCACFは、Ansible Towerを中核とした自動化プラットフォームであり、GUI操作による利用者のAnsibleに対する学習コストの削減や充実したRest APIによるIT管理プロセスとの連携が強みとなる。
ITSMリクエスト・ワークフローとAnsible TowerをAPIで連携することで、エンドユーザーの依頼をトリガーにしたEnd to Endの自動化を実現し、かつ運用担当者の製品や作業内容ごとにサイロ化された自動化のプラットフォーム統一が可能となる。
現在は、クラウド基盤上のサービス・リクエスト作業で依頼頻度の高いデータベースのレコード取得に向けた自動化を実現している。
今回紹介した実装例をほかのサービス・リクエスト作業に展開することで、定型化されたエンドユーザーの依頼に基づく運用業務をすべて自動化し、自動化2.0の実現を加速させられる。
継続的な自動化を進めるために
筆者が参画したプロジェクト事例をもとに、過去数年にわたるインフラ運用自動化の取り組みを紹介したが、Infrastructure as Codeの概念に基づいたクラウド基盤を構築・運用することで、以下のように、これまでになかった自動化固有の課題を発見できた。
・自動化基盤はさまざまなシステムと連携する必要があるため、自動化対象のコンポーネントすべてが製品サポートのマトリックスを満たす検討対象となる。今後も自動化基盤での新規開発を伴う場合は、既存資産をImmutable Infrastructureとして、システム全体をまとめて凍結する判断も時には必要となる。
・クラウドが普及した世界での製品やサービスのライフサイクルは、すでに数カ月に1度のペースでバージョン／リリースアップを繰り返しているため、インフラIT運用自動化の世界でもソフトウェア開発時と同様に高い互換性の保証が求められることになる。
クラウドネイティブの概念を取り入れたIT運用の自動化は、今後も飛躍的に進んでいく。本稿の自動化事例が、カスタマーファーストを考慮した業務最適化に少しでも役立てば幸いである。
著者｜
竹屋 正樹 氏
キンドリルジャパン合同会社
テクノロジー本部 クラウド
ハイブリッドクラウドビジネスイノベーション
ITアーキテクト
2016年、日本IBMに入社。2021年、IBM分社化に伴いキンドリルジャパンに移籍。Infrastructure as Codeの概念に基づき、システム構築・運用業務を自動化するプラットフォームの設計・実装を実施。近年はエンタープライズ・システムへのSRE実装に携わり、クラウドネイティブ技術の価値をユーザーに提供するための取り組みを行っている。
小栗 直樹 氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
テクニカル・コンピテンシー
オープン・テクノロジー
コンサルティングITスペシャリスト
（2021年6月より出向中）
日本アイ・ビー・エム株式会社
テクノロジー事業本部
カスタマー・サクセス
近年はKubernetes、OpenShiftをはじめとしたIBMのクラウド基盤ソリューションの製品技術支援、ならびに案件でのシステム自動化連携部分の開発・実装に従事。個々の案件では、Infrastructure as Code からIT サービス基盤との連携における自動化基盤の運用実現・定着を推進。2021年6月より出向している日本IBMでは、IBMの戦略的オファリングであるCloud Paks、IBM Cloudのさらなる利活用のために創設された新たな部署でのロールに取り組む毎日を送っている。
［i Magazine・IS magazine］
