日本CTO協会は「技術」を軸に規模や業種の異なる様々な人や組織が集まっているコミュニティです。会員は本社団の活動内容、調査テーマについて参加、提案し、他の技術者・技術組織とともに成長する機会が得られます。ご興味のある方は法人会員向け申し込みフォームからお問い合わせください。

複雑化する傾向のある開発の現場で最適なテクニックやツールを選べていますか？

Infrastructure as Code (IaC)という言葉は、もはやソフトウェア・エンジニアリングに携わる人にとっては常識レベルに浸透してきていると言っても、過言ではないかもしれません。しかし実際のところ、どういう点に気をつけるべきなのか、具体策に悩んでいる人も多いのではないでしょうか？本記事ではコードとしてのインフラストラクチャ、そしてフィーチャートグルをどのように活用すればそれらのツール・テクニックの利点を生かせるのか、深掘っていきます。

前回の「2020年のエンジニアなら、知っておきたい。リモートネイティブという選択。」に引き続き、世界のシニア技術者のおすすめ最新情報をまとめたレポート（Technology Radar）で紹介されていたテクニック・ツールを中心に紹介していきます。これらのテクニックについて他の海外の論文、ブログ、レポートを交えて紹介し、ツールに関する本協会CTOからの評価やコメントも記載しておりますので、ぜひ参考にしていただき、実践してみていただけたら嬉しく思います。

また、TechnologyRadarの各項目は更新されていくものであるため、更新・追加・新登場かどうかも直感的にわかるように表現されている。Newは新しく追加された項目、Movedin/outは以前紹介されたことがあるが所属リングが更新された項目、No Changeは以前紹介されている項目を指している。

あくまでもこれらの項目はThoughtsWorks社が独自の目線でピックアップし、分類したものである。それを考慮した上で、自社に採用できるツールを探すことはもちろん、次に定着しそうなツールはなんだろう、と言った別の目線でリングや新登場の情報を読み進めるのも面白いかもしれない。

ちなみにGoogle Sheetのテンプレートを使えば自分だけのRadarを作成することもできる（https://www.thoughtworks.com/radar/how-to-byor）

ソフトウェアデリバリーのエコシステム

ソフトウェアデリバリーのエコシステムのテクニック

Technology Radarではソフトウェアデリバリーのエコシステムに関する様々なテクニックを紹介しているが、これらの項目で共通しているのは自動化、継続的な監視、効率化などが鍵となっていることだ。パイプラインやインフラストラクチャのコード化(Infrastructure as Code)を行うことで、自動的に構築、検証、デプロイ、監視を一貫してこれらの領域に適用することが勧められている。また、フィーチャートグルなどの使用は使用目的に応じてできるだけシンプルなものにするといいだろう。

コードとしてのインフラストラクチャ (Infrastructure as code (IaC)) 

• Adopt – No Change

コードとしてのインフラストラクチャ(IaC)は2011年のRadarでも紹介されている。インフラストラクチャを設定する行為がクラウドプラットフォームへの設定指示の受け渡しになっているため、非常に重要になってきている。ThoughtsWorks社(2020)は「コード化」をソフトウェアの世界で得た良い習慣をすべてインフラストラクチャに適用することだと説明している。ソース管理の使用、DRY原則の遵守、モジュール化、メンテナンス性、自動テストとデプロイの使用は、すべて重要なことで、インフラストラクチャの領域全体に一貫して適用する必要がある (ThoughtWorks Technology Advisory Board 2020)。

IaCの導入メリットとしては以下が挙げられる(Fernandez 2020)。

スピード	手動介入を避けることで、インフラストラクチャの導入は迅速かつ安全に行われる。
ソース管理	ソース管理でコードをチェックすることで、透明性と説明責任を高めることができる。
ドキュメンテーション	IaCは、インフラストラクチャの実際の状態を示す生きたドキュメントとして機能する。
一貫性	統一して同様のインフラストラクチャを展開し、エッジケースや単発の構成を回避する。
アジリティ	DevOps はソフトウェアのデリバリをより効率的にし、IaC はインフラストラクチャ管理の領域にアジリティをもたらす。
再利用性	IaCは、再利用可能なモジュールの作成を容易にする。例えば、開発環境と本番環境の複製などだ。

IaCの手順は大まかに3段階あり、以下の図にまとめられる(Fernandez 2020)。

1. まず開発者は、ドメイン固有の言語でインフラストラクチャの仕様を記述する。
2. 結果として得られたファイルは、マスターサーバー、管理API、またはコードリポジトリに送信される。
3. プラットフォームは、コンピュータリソースを作成して設定するために必要なすべての手順を実行する。

次にIaCの利点を最大限引き出すためにThornTechnologies社が勧める以下の6点を実践してみよう(Chan 2018)。

1.　全てをコーディングする

すべてのインフラストラクチャの仕様は、AWS CloudFormation テンプレート、Chefレシピ、Ansibleプレイブック、または使用しているその他のIaCツールなどの設定ファイルで明示的にコーディングされている必要がある。これらのファイルがインフラストラクチャの基盤となり、誰もサーバーにログインして手動で調整を行う必要が無いのが理想と言えるだろう。

2.　ドキュメントは可能な限り最小限に

IaC コードは基本的にドキュメントになるため、追加の指示は多くないはずだ。過去には、インフラストラクチャのコンポーネントが更新された場合、矛盾を避けるためにドキュメントをロックステップで更新する必要があった。インフラストラクチャの導入プロセスにあまり慣れていない社員を教育するために、図やその他のセットアップ手順などの追加のドキュメントが必要になるかもしれない。しかし、導入ステップのほとんどは設定コードによって実行されるので、このドキュメントは最小限に抑えるのが理想的だ。

3.　バージョン管理の維持

インフラストラクチャの設定ファイルはバージョン管理され、詳細はコードで書かれているので、コードベースへの変更は管理、追跡、調整が可能だ。アプリケーションコードと同じように、Git、Mercurial、Subversionなどのソース管理ツールを使用して、IaCコードベースのバージョンを管理しよう。これはコード変更の記録だけでなく、本番前に共同作業やピアレビュー、IaCコードのテストを行うためにも便利である。コードの分岐とマージのベストプラクティスは、開発者のコラボレーションをさらに促進し、 IaC コードの更新が適切に管理されていることを保証するためにも使用されるべきだ。

4.　継続的なテスト、統合、デプロイ

継続的なテスト、統合、およびデプロイのプロセスは、IaCに加えられるすべての変更を管理するための優れた方法だ。テストは、デプロイ後に問題が発生しないように非常に重要な役割を果たす。ニーズに応じて、ユニットテスト、リグレッションテスト、統合テスト、その他多くのテストタイプを実行する必要がある。自動テストは、構成コードに変更が加えられるたびに実行するように設定することもできる。このようにテスト、セキュリティ、開発の連携を強化することで、バグや脅威を開発ライフサイクルの早い段階で発見し、本稼働時に最小限に抑えることができる。健全な継続的インテグレーションプロセス(CDP)があれば、これらの構成テンプレートは、開発、テスト、QAなどの異なる環境で再利用することができる。開発者は一貫性のあるインフラストラクチャ構成で、各環境の作業を行うことができる。この継続的な統合により、インフラストラクチャが本番環境にデプロイされたときに、アプリケーションに有害なエラーが発生するリスクを軽減することができる。

5.　インフラストラクチャのコードをモジュール化

製品の残りのコンポーネントから独立してデプロイできる、より小さくてモジュール化されたコード単位を開発することがトレンドとなっている。同じコンセプトをIaCにも適用することができる。インフラストラクチャを個別のモジュールやスタックに分解し、自動化された方法でそれらを組み合わせる。このアプローチにはいくつかの利点がある。まず、インフラストラクチャのコードのどの部分に誰がアクセスできるか、管理が可能になる。たとえば、インフラストラクチャ構成の特定の部分に精通していなかったり、専門知識を持っていなかったりするジュニアエンジニアがいるかもしれない。インフラストラクチャのコードをモジュール化することで、ジュニアエンジニアがスピードを上げるまで、これらのコンポーネントへのアクセスを拒否することができる。また、モジュール化されたインフラストラクチャは構成に加えられる変更の量が制限される。小さな変更であれば、バグの検出が容易になり、チームはより俊敏に行動できるようになる。また、マイクロサービス開発アプローチを使用する場合は、インフラストラクチャの一貫性を確保するために、各マイクロサービスごとに構成テンプレートを作成することができる。そうすれば、すべてのマイクロサービスをHTTPやメッセージングインターフェースを介して接続することができる。

6.　可能な場合はインフラストラクチャを不変（イミュータブル）のものに

変更可能なミュータブルのインフラストラクチャは時間が経つにつれて、より多くのアップデートを適用すると、各サーバーに固有の変更履歴が蓄積されていく(Brikman 2016)。よって、設定ドリフト(configuration drift)と呼ばれる現象に直面することがある。各サーバが他のすべてのサーバと微妙に異なるものになり、診断が困難で再現がほぼ不可能な微妙な設定バグが引き起こされる。一方、不変型（イミュータブル）のインフラストラクチャとは、ITインフラストラクチャのコンポーネントがその場で変更されるのではなく、デプロイのたびに交換されるというものだ。インフラストラクチャスタックのコードを一度書いてデプロイし、それを複数回使用しても、決して変更することはない。構成を変更する必要がある場合は、そのスタックを終了させてゼロから新しいものを構築すればよい。インフラストラクチャを不変にすることで一貫性が得られ、設定のドリフトを回避し、文書化されていない変更がスタックに与える影響を制限する。また、セキュリティが向上し、設定の編集がないためトラブルシューティングが容易になる。

IaCを実際導入しようと思ったときに悩むのがツールの選択だ。Chef、Puppet、Ansible、SaltStack、CloudFormation、Terraformなどが名の知られているツールだろう。これらのツールの導入目的は主に3つ挙げられる (Nayak 2019)。1つ目がコンピュート、ストレージ、ネットワークコンポーネント、データベース、Kubernetesクラスターなどのプラットフォームサービスのインフラストラクチャリソースの作成、変更、破壊だ。2つ目がインフラストラクチャの上にアプリケーションを配置し、更新する場合だ。3つ目がアプリケーションで使用されている設定を管理するためだ。しかしこれらのツールの違いは一見理解しづらく、どのようにして使用するべきか悩ましい。様々な切り口で分析することが可能だが以下ではツールの見分け方を3つ紹介する。より詳しい違いを知りたい読者は参考文献より原文にも目を通して欲しい。

構成管理とプロビジョニング(Configuration Management vs Provisioning)

まず構成管理(Configuration Management (CM))とプロビジョニング(Configuration Provisioning)の違いを理解しよう。CMはシステムの構成と提供するサービスの構成を、すべてコードで繰り返し一貫して管理するために使用される(Nuñez 2017)。これらのツールの多くは、直感的なコマンドラインインターフェース、軽量で読みやすいドメイン固有言語（DSL）、他のツールとの統合をしやすくするRESTベースのAPIの3つの方法でこれを実現する。人気の高いオープンソースのCMツールがChef、Puppet、Ansible、SaltStackなどだ。

既存のサーバーにソフトウェアをインストールして管理するように設計されているCMに対して、Configuration Provisioningのツールはサーバー自体をプロビジョニングするように設計されている (Brikman 2016)。同様にデータベースやネットワーク設定などのインフラストラクチャの残りの部分も扱われ、サーバーの設定作業は他のツールに任せる。代表例がCloudFormationとTerraformである。

ほとんどのツールはある程度この2つのカテゴリを行うことができるので完全に切り離して捉える必要もない。しかし、この違いを理解するとプロジェクトに合わせて的確にツールを選び、うまく組み合わせて使用することもできる。例えばTerraform を使用して、ネットワークトポロジー（VPC、サブネット、ルートテーブル）、データストア（MySQL、Redis など）、ロードバランサー、サーバーなど、基盤となるインフラストラクチャをすべてデプロイする (Dharmalingam 2019)。そして、Ansible を使用して、これらのサーバーの上にアプリをデプロイする。

可変型インフラストラクチャと不変型インフラストラクチャ (Immutable Infrastructure vs Mutable Infrastructure)

上記では不変型（イミュータブル）のインフラストラクチャのメリットについて説明したが、従来のサーバー環境は、インストール後に変更されるミュータブルなものが多い。Chef、Puppet、Ansible、SaltStackなどのCMツールは、一般的にデフォルトでは可変型（ミュータブル）インフラストラクチャのパラダイムになっている。一方Terraformなどのツールでは不変性がリソースの作成から破棄までのライフサイクルを管理するためのサポートに組み込まれているため、サーバに簡単に適用できる。

手続き型と宣言型 (Procedural vs Declarative)

ChefとAnsibleは手続き型(Procedural)を推奨しており、希望する最終状態を達成する方法をステップごとに指定するコードを書く(Brikman 2016)。Terraform、CloudFormation、SaltStack、Puppetはすべて、より宣言的なスタイル(declarative)を推奨しており、希望する最終状態を指定するコードを書き、IaCツール自体がその状態を達成する方法を見つけ出す。手続き型はスクリプトのバックグラウンドを持つシステム管理者により馴染みがあり、宣言型はプログラミングの経験がある人にはより使いやすいという(Strutt 2018)。

パイプラインのコード化 (Pipelines as code)

• Adopt – No Change

IaCで説明したような内容はパイプラインにも応用することができる。パイプラインのコード化は、アプリケーションやインフラストラクチャを構築、テスト、デプロイするデリバリーパイプラインの構成をコードとして扱うべきであることを強調している。組織が分散型の自律型チームに移行するにつれ、一貫したソフトウェアの構築とデプロイを維持するために、パイプラインをコードとして管理するエンジニアリング手法の必要性が高まっている。パイプラインをコードとして構築、テスト、デプロイする能力は、CI/CDツールを選択する際の評価基準の一つにもなるはずだ。

最もシンプルなフィーチャートグル (Simplest possible feature toggle)

• Adopt – New

フィーチャートグルは、ユーザーに新しい機能を提供する方法を制御するためのパターンと言えるだろう。ある意味、単なる条件文のようなもので、「オン」と「オフ」を簡単に切り替えることができる。フィーチャートグルは主にリリーストグル(Release toggles)、実験トグル(Experiment toggles)、オペレーショントグル(Ops toggles)、限定トグル(Permissioning toggles)の４種類に分けられる(Hodgson 2017)。以下では各トグルについてmartinFowlerのHodgson(2017)の解説を紹介する。

リリーストグルは継続的デリバリーを実践しているチームがトランクベースの開発を可能にするために使用される。進行中の機能をチェックしながら、共有の統合ブランチ（マスターやトランクなど）をいつでも本番環境にデプロイできるようにする。リリーストグルを使用すると、不完全なコードパスやテストされていないコードパスを、決してオンにならない潜在コードとして本番環境に出荷することができる。Git-flowやGithub Flowのようなブランチに大きく依存している強固なワークフローはあるが、GoogleやFacebookも含めてより多くの組織がいわゆるトランクベースの開発を採用している(Tsvetkov 2017)。

実験トグルは A/B テストなどを実行するために使用される。システムの各ユーザはコホートに配置され、実行時にトグル・ルーターはユーザがどのコホートにいるかに基づいて、指定されたユーザを通して一方のコードパスまたは他方のコードパスに送る。異なるコホートの集約的な動作を追跡することで、異なるコードパスの効果を比較することができる。このテクニックは、Eコマースシステムの購入フローやCall To Action(CTA)ボタンの文言など、データ駆動型の最適化を行うためによく使用される。一過性のリリーストグルとは異なり、実験トグルは、新しい機能が成功するかどうかが明らかになるまで、しばらくの間コードの中に存在することができる。

オペレーショントグルはパフォーマンスへの影響が不明瞭な新機能を使用する際に、システム・オペレーターが必要に応じてその機能を本番環境で迅速に無効化または劣化させることができるように導入する。そのため比較的短命で、新しいリリースをデプロイした後の運用上の問題を解決するためだけに使用される。

最後の限定トグルは特定のユーザーが受け取る機能や製品体験を変更するために使用される。例えば、「プレミアム」機能のセットがあって、それを有料のお客様だけが利用できるように設定している場合。あるいは、内部ユーザーのみが利用できる「アルファ」機能と、内部ユーザーとベータユーザーのみが利用できる「ベータ」機能のセットがある場合。許可トグルは他と比べてもかなり長く使うことが一般的で、数年使用することもある。

これらの特徴をまとめた図が以下だ。ますは静的トグルと動的トグルで分類分けすることができる。単純なルーチンの場合トグル設定は単純なオン/オフで、トグル・ルータはその静的なオン/オフ状態をトグルポイントに中継するだけの役割を果たす。他のカテゴリのトグルはより動的で、より洗練されたトグルルータが必要になる。

次に一般的な使用期間で分けることができる。この区別は、フィーチャートグルを実装する際のアプローチを強く左右する。数日後に削除される予定のリリーストグルを追加する場合は、単純な if/else チェックを行うトグルポイントで十分だ。逆に新しい許可トグルを作成して非常に長い間使用する場合は、無差別にif/elseチェックを散りばめてトグル・ポイントを実装することは避け、もっと保守性の高い実装技術を使う必要があるだろう。

以上を踏まえた上で、このテクニックの本題に戻ろう。よく見受けられる失敗はこれらのフィーチャートグルの種類と使用方法を混同してしまうことだ。例えば継続的インテグレーション(CI)の恩恵を受けるためにLaunchDarklyのような強力なプラットフォームを使う人をしばしば見かける (ThoughtWorks Technology Advisory Board 2020)。しかし、if/else条件さえあれば事足りる場合が多く、不必要に複雑なフィーチャートグルフレームワークを使用するのは非効率的だと考えられる。ThoughtsWorks社はA/Bテストやカナリアリリースが必要な場合や、機能のリリース責任をビジネス担当者に委ねる場合を除き、可能な限りシンプルなフィーチャートグルを使うことが勧めている。つまり、動的で比較的長い期間使うことになる限定トグルなどは高い実装技術も必要で管理が難しいため注意するべきだろう。まずは最もシンプルなリリーストグルで事が足りるのかどうか考えてみるのがいいのではないか。

ソフトウェアデリバリーのエコシステムのツール

ここで紹介するツールは上記で紹介したコードとしてのインフラストラクチャ・パイプライン等をサポートするためのものが記載されている。しかしフィーチャートグルに関するテクニックで説明した様に、必ずこれらを導入すればうまくいくというわけではなく、各企業が自分の組織には何が必要なのか戦略的な目線で参考にしてほしい。

tfsec

Asses – New、IaCと関連

　インフラストラクチャをコードとして扱う際、Terraformがクラウド環境を管理するための選択肢の一つである。そのTerraformのテンプレートをスキャンして潜在的なセキュリティ問題を発見するための静的分析ツールであるtfsecが登場した。tfsecには、AWSやAzureを含むさまざまなクラウド・プロバイダ用のプリセット・ルールが用意されている。セキュリティリスクの特定に優れているだけでなく、インストールや使用も簡単だ。

ConfigCat

Asses – New、Simplest Possible Feature Toggleと関連

　ダイナミックなフィーチャートグルをサポートするサービスを探しているのであれば(シンプルな機能トグルでも十分に機能することを覚えておいてほしい)、ConfigCatをお勧めする。「LaunchDarklyのようだが、安くて派手さを控えめにしたもの」とThoughtsWork社では表現しており、必要としていることのほとんどを実現しているという。ConfigCatはシンプルな機能切り替え、ユーザーセグメンテーション、A/Bテストをサポートしている。

K9s 

Trial級 – New、IaCと関連

　インフラストラクチャのコード化を実現するには高精度のモニタリングが必要となる。AWSのウェブコンソールのようなインタラクティブなツールが役に立つこともあるだろう。コマンドをいちいち覚えなくても、アドホックな方法であらゆる種類のリソースを探索することができる。しかし、インタラクティブなツールを使ってその場で手動で変更を加えるのにはまだ疑問が残る。そこで、k9sはkubectlができることのすべてにインタラクティブなインターフェースを提供する。ウェブアプリケーションではなく、ターミナルウィンドウの中で動作することも特徴だ。

日本CTO協会でのアンケートの結果

これらのツールに関しては本協会所属のCTOに使用しているかどうかアンケートを行い、28名から回答を得た。これらのツールの領域は広いため、あるツールを使用していても他は使用していないというケースもあり、必ずしもアンケート結果が普及率を正確に表しているわけではない。しかし、この調査によって日本のCTOはこれらのツールをどう捉えているのか、参考程度に合わせて読んでいただきたい。

　tfsec – 1名：Security as Codeの文脈から調べると面白そうというコメントがあった。

　ConfigCat – 1名：使用しているCTOが少なかった。フィーチャートグルは自社にあったものを使うのが最適というテクニックを考慮するとこのツールを必ず使用すればいいというものでもないので、吟味して採用していくのが最適なのではないか。

　k9s – 1名：知名度も使用度も低かったが、 Kubernetes クラスタの操作性を向上させるための CLIツールとして注目していきたい。

最後に

前回と比較してガラッと内容が変わった本記事ですが、いかがでしたか？本記事でのツール・テクニックの情報をあくまでも参考とし、今後自社にあった戦略そしてツールを模索してほしいと思っております。以下には本記事のまとめを記します。

「インフラストラクチャ・パイプラインをコード化することで自動化、一貫性、リスクの軽減を実現する」

「フィーチャートグルはできる限りシンプルにして複雑化を防ぐ」

次回の世界のエンジニアに学ぶシリーズではセキュリティに関するテクニックを紹介します。

引用文献

Brikman, Yevgeniy
2016 Why We Use Terraform and Not Chef, Puppet, Ansible, SaltStack, or CloudFormation. Medium. https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c, accessed September 17, 2020.

Dharmalingam, N
2019 Ansible vs Terraform: Understanding the Differences. Whizlabs Blog. https://www.whizlabs.com/blog/ansible-vs-terraform/, accessed September 17, 2020.

Fernandez, Tomas
2020 What Is Infrastructure as Code? How Infrastructure as Code Works. Articles for Developers Building High Performance Systems. https://blog.stackpath.com/infrastructure-as-code-explainer/, accessed August 14, 2020.

Hodgson, Pete
2017 Feature Toggles (Aka Feature Flags). Martinfowler.Com. https://martinfowler.com/articles/feature-toggles.html, accessed August 14, 2020.

Nayak, Ramnath
2019 When to Use Which Infrastructure-as-Code Tool. Medium. https://medium.com/cloudnativeinfra/when-to-use-which-infrastructure-as-code-tool-665af289fbde, accessed September 17, 2020.

Nuñez, Carlos
2017 Why Configuration Management and Provisioning Are Different. ThoughtWorks. https://www.thoughtworks.com/insights/blog/why-configuration-management-and-provisioning-are-different, accessed September 17, 2020.

Strutt, Steve
2018 Infrastructure as Code: Chef, Ansible, Puppet, or Terraform? https://www.ibm.com/cloud/blog/chef-ansible-puppet-terraform, accessed September 17, 2020.

ThoughtWorks Technology Advisory Board
2020 Technology Radar | An Opinionated Guide to Technology Frontiers　Vol.22. https://www.thoughtworks.com/radar?utm_source=en&utm_medium=pdf&utm_campaign=techradar-vol22, accessed August 3, 2020.

Tsvetkov, Alexander
2017 Feature Toggles in .NET: Tips and Tricks. Surfing the Code. https://surfingthecode.com/feature-toggles-in-.net-tips-and-tricks/, accessed August 14, 2020.

執筆担当者

日本CTO協会　竹谷真帆

有志

C Channel株式会社 執行役員　小野邦智
株式会社シンシア 代表取締役社長　徐聖博

日本CTO協会

担当理事 名村卓(株式会社メルカリ 執行役員)
PM 松下清隆

---

日本CTO協会ではメールマガジンに登録いただいた方に定期的に最新レポートの情報や本協会の活動をお届けしています。