CodeZine(コードジン)

特集ページ一覧

コードとしてITインフラを定義する――自動化を超えた継続的改善の実現とは

トップエスイーからのアウトカム ~ ソフトウェア工学の現場から 第13回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

目次

不確実性への対処:計画主導と検証主導

 ウォーターフォール的なアプローチは計画主導の方法です。不確実性を計画の段階でできるだけ排除し、除去しきれなかった不確実性には計画したバッファ期間を持って吸収していきます。それに対してアジャイル的なアプローチは検証主導であると言えます。こちらは実際に動くものを作成して、そこに生じるギャップを検証し対処することで不確実性を除去していきます。

 計画主導と検証主導はそれぞれ前提とする不確実性の条件が異なっています。計画主導においては「計画時に考慮した不確実性はプロジェクトが進んでも変化しない」という前提を置きます。一方、検証主導の考え方では、「不確実性は絶えず変化する」という前提を置きます。

図2 計画主義と検証主義の違い
図2 計画主義と検証主義の違い

不確実性の具体例

 ITインフラにおける不確実性と言われても、ピンとこない方もいるかもしれませんが、実はすごく単純なものです。ITインフラに不確実性を持ち込む代表的な要因とは「変化」です。例えば以下のような変化を考えてみてください。

  • セキュリティホールが見つかりパッチを当てる。
  • 特定機能に不具合があったのでソフトウェアのバージョンを上げる。
  • EOLに伴い新しいソフトウェアに入れ替える。
  • システムの機能拡張に伴い新規のミドルウェアを導入する。
  • 設定に不備があったので設定を変更する。
  • 利用者が増加、減少したのでシステムのリソースを増減する。
  • 会社の事業買収、売却に伴いネットワークの接続先が変更される。

 こうした変化はシステムに対して不確実性をもたらす要因であると言えます。「パッチを当ててもシステムは問題なく動くのか」「新しいソフトを導入して既存機能と共存できるのか」「設定を変更して他の部分に影響は出ないのか」など、多数の「不安要素=不確実性」を生み出しています。

 他にもシステムを構築し、維持していくために立ちはだかる多様な不確実性があります。市場や社会、会社の状況などシステムが置かれた環境に起因する不確実性。どのようなシステムやサービスを作っていくのかといった目的に起因する不確実性。システムをどのような技術でどうやって構築運用していくのかといった方法に起因する不確実性。システムに関わる人員のコミュニケーション(理解、伝達、能力など)に起因する不確実性です。

 少し観点は違いますが、ソフトウェア開発におけるウォーターフォールとスクラム(アジャイル)について比較した記事がこちらにありますので興味があればご一読ください。ここでもポイントになるのは「変更(=不確実性)」です。

検証主導を実現するIaCとインフラCI

 計画主導による手法では、これらの不確実性を可能な限り計画の段階で除去していきます。例えば「採用するソフトウェアのバージョンは固定化する」などの方法です。このように前提を固定化し、計画後に生じる変化によって不確実性がシステムへと入り込まないように管理していきます。これは実に装置産業的な考え方だと言えます。装置は設置した時に機能が固定化され、基本的にそこから変わることはめったにありません。不確実性を予測可能な範囲に抑え込むことができればリーズナブルな手法です。

 それに対して検証主導による手法では、不確実性を固定化せず、変化は起こりうるという前提で、変化が生じるたびに影響範囲を検証して対処していくことになります。これは一見すると効率が悪い方法に見えるかもしれません。なんらかの変化が生じるたびに実際に動く環境で検証を行っていては、どれだけ確実性が高くとも膨大なコストと時間が必要になってしまいます。しかし、現在ではこれを現実的なコストと時間の中で可能としていく方法があります。それがIaCになります。

 IaCはITインフラに関わる不確実性を除去していくために幅広いテーマを扱います。この中でも特に、持続可能なシステム開発と継続的な改善を行うためのプラクティスに注目し、このプラクティスを適用して検証主導のITインフラを実現していく方法を「インフラCI(インフラにおける継続的インテグレーション)」と呼びます。

インフラCIで変わること

 インフラCIではこの検証主導を実現するために大きく2つのものが必要となります。システムの要件に従い実際に動く環境を構築する「自動構築の仕組み」と、ギャップの測定を行うために要件への適合を判定するための「自動化されたテスト」です。この自動構築は従来であれば環境を構築するための手順書であり、自動テストは「システムのあるべき状態や望む振る舞い」を確認する、テスト仕様書のようなものと本質は同じです。

 自動構築と自動テストはどちらを先に準備しても構いませんが、あえて先に自動テストを実装して、そのテストに適合するように自動構築を実装していく手法を「テスト駆動開発」と呼びます。

 この2つがそろうと、まず環境の自動構築を実行して環境を構築し、その後に自動テストを実行してエラーが発生しなければ、要件に適合した環境を構築できたと言うことができます。なんだ、当たり前じゃないかと思われるかもしれません。それに、初期の構築でこんな手間をわざわざかけ、構築とテストを自動化する意味もわからないかもしれません。確かに、ウォーターフォール的なアプローチで対応できる環境ではこの手法は単なる労力の無駄遣いでしょう。

インフラCIで不確実性と対峙する

 しかし、要件や周囲の環境が変化する状況を想像してみてください。一度作った環境に対して、時間経過と共にさまざまな不確実性が発生します。先に述べた環境、目的、方法、通信などの不確実性やそれらが複雑に絡まり合い、より大きな不確実性を生み出していきます。この不確実性に対処するために、先に自動化した構築とテストが有効に働きます。

 まず、検証環境にて本番で使った自動構築を実行します。これで本番と同等の環境が再現されます。これが本番と同等であるかは自動テストを実行することで確認できます。この状態で、不確実性の1つ(例えばパッチ適用など)を環境に適用します。その後、自動テストを実行して全ての結果がOKであると判定されたとします。これは何を意味するのでしょうか。仮にテスト結果がNGだった場合でも同じことを意味しています。

 このテスト結果は、「発生した不確実性が1つなくなった」ということを意味しています。テスト結果がOKであれNGであれ、このテストで「パッチを当てるとどうなるかわからない」といった不確実性が解消されたのです。この際、人が実際に操作することはほとんどありません。構築もテストも自動化されているためです。つまり、発生する変化が多いシステムほど、インフラCIの仕組みは効果を発揮していきます。

 このように、構築とテストを自動化しておき、不確実性が発生するたびに自動で検証のサイクルを回して不確実性を取り除いていくのがインフラCIになります。これは典型的な検証主導の例であると言えます。

図3 インフラCIによる不確実性の解消
図3 インフラCIによる不確実性の解消

インフラCIを実現するには

 ここではインフラCIに関して2つの要素しか紹介していませんが、実際には自動化のコードを管理するバージョン管理システム(VCS)、VCSと連携してコードの変更に対してシナリオを自動実行するCIツールなど、さまざまな要素が登場してきます。まさにこうしたツール類はソフトウェア開発の中で活用され発展してきたものばかりです。これらをうまく活用していくことで、ウォーターフォールでは対応が難しかった、不確実性の多いシステムに対しても安全に効率よく対応していくことが可能となります。

 インフラCIに関してはネット上でも多数の情報を見つけることもできます。最近では情報がまとまった書籍『インフラCI実践ガイド Ansible/GitLabを使ったインフラ改善サイクルの実現』(翔泳社)なども出始めており、今後ますます世の中に浸透していくことは間違いないでしょう。この動きはクラウドなどの新しいプラットフォームの活用が進んでいることと深い関係があります。今後みなさまが新しいシステムのITインフラを検討する際には、ぜひこの「不確実性への対処」という視点を持って取り組んでいただければ幸いです。

トップエスイーについて

 「トップエスイー」は、国立情報学研究所で実施している、社会人エンジニア向けのソフトウェア工学に関する教育プログラムです。トップエスイーでは講義や制作課題を通して、最先端の研究成果や現場で得られた知見が蓄積されてきました。その「アウトカム」、つまり成果やそこに至る過程を紹介し、現場のエンジニアの方々に活用いただける記事を連載しています。今回の記事で紹介したIaCについては、2018年12月7日に開催されるトップエスイーのセミナー「Infrastructure as Code によるITインフラの継続的改善」として受講できます。講師は本記事の筆者である中島倫明が務めます。トップエスイーは年間コースですが、セミナーはどなたでも受講できます。ITインフラの管理手法を一歩進めたい方々や、IaCを実践的に習得したいと考えている方々には、絶好のチャンスです。



  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:トップエスイーからのアウトカム ~ ソフトウェア工学の現場から

もっと読む

著者プロフィール

  • 中島 倫明(レッドハット株式会社)(ナカジマ トモアキ)

    @irix_jp(Twitter)  国内SIerを経て、現在はレッドハットへ勤務。戦略から実装まで、幅広く企業システムの自動化やクラウド化の促進を支援。その傍らで大学や研究機関での講師を勤め、クラウド時代のIT人材の育成に尽力する。OpenStackやAnsibl...

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5