IBM Developer Japan Webサイトは2021年3月15日をもって終了となり、日本語コンテンツの一部は、オープンソースとして、提供予定です。 URLはこちら

コードとしてのインフラストラクチャーとは?

こんにちは。IBM CloudチームのSai Vennamです。本日はInfrastructure as Codeについてお話しします。

昨今ではインフラストラクチャーの自動化が重要視されつつあります。アプリケーションを1日に何百回も本番にデプロイできるからです。また、インフラストラクチャーを迅速に更新でき、負荷に応じたプロビジョンやプロビジョン解除も可能です。

alt

[Kubernetesアプリケーション・スタック]

では例を挙げて見ていきましょう。アプリケーションを開発中で、既にパブリック・クラウドを使用しているとします。まず、Kubernetes上にアプリケーションをビルドすることにしました。ここにKubernetesアプリケーション・スタックを配置します。

alt

Kubernetesの詳細を確認する必要はありません。Kubernetesはアプリケーション層からハードウェアを切り離すからです。細かい設定は不要です。Kubernetesがユーザーに代わって管理します。

[VM]

開発の1週間後、モダナイズしていないレガシー・アプリケーションをホストするVMを導入することにしました。VMを導入します。

alt

これらの構成要素を接続するためにVPCが必要です。これで基本的なインフラストラクチャーが整いました。

alt

[テスト・フェーズ]

では、開発が順調に進んだとしましょう。インフラストラクチャーの詳細がすべて文書化され、テスト・フェーズに移行する準備ができました。

ベスト・プラクティスは、まったく新しい環境を構築して、この開発環境を再現することです。そのために文書を再確認し、手順に従ってインフラストラクチャーを稼働させようとしました。

alt

ところが、configスイッチを変更したことを文書に反映するのを忘れていました。あるいは、プラットフォームが別の方法でインフラストラクチャーをプロビジョンしているのかもしれません。

いずれにせよ、新しい環境ではアプリケーションとテストが以前と同様に動作しません。この問題を解決し、今後はこのような問題が起こらないようにする必要があります。

それにはInfrastructure as Codeが必要だと判断しました。

[命令型アプローチ]

それでは、インフラストラクチャー自動化の最初のアプローチを見ていきましょう。それが命令型です。これは大半の人にとってわかりやすいアプローチです。なぜなら、特定のインフラストラクチャーを構築する方法を、段階的に定義できるからです。

alt

一般的に、命令型アプローチではCLIやBashスクリプトなどを使用します。例えば、このケースではCLI Create Kubernetesを実行します。

alt

その後、別のコマンドをいくつか定義してKubernetesのデプロイメントをカスタマイズします。VMとVPCにも同様の処理を実行します。

alt

[命令型アプローチの利点]

命令型アプローチには利点があります。インフラストラクチャーのプロビジョニングを手順を追って定義できます。ここではクラウド・ツールを使用して、段階的なプロセスでアプローチを実行するので、総体的に効率性も高まります。ただしその一方で少し複雑になります。

例えばVMや環境を停止したり、環境を拡張または縮小したりする場合は、カスタム・スクリプトを作成する必要があります。これは命令型アプローチでは処理されません。したがって多くの場合、命令型はスケーリングに適していません。

[宣言型アプローチ]

インフラストラクチャー自動化のもう一つのアプローチは宣言型です。私はこちらの方が気に入っています。宣言型アプローチにはTerraformなどがあります。基本的に、ユーザーはインフラストラクチャーの最終状態を定義し、それ以外はプロバイダーに任せることができます。

alt

すべての手順を定義するのではなく、最終状態のみを定義します。この例ではKubernetesリソース、VMリソース、VPNまたはVPCリソースを定義します。

alt

[宣言型アプローチの利点]

宣言型のもう一つの利点は、シンプルなConfigMapで管理できることです。ホストの定義やドメイン、サブネットの定義も可能です。一般的に、宣言型アプローチでは構成をより簡単に管理できます。私はインフラストラクチャーの自動化には、宣言型アプローチを選択します。

alt

このシンプルな例で、命令型スクリプトを複数回実行すると最終的に複数の環境ができます。さらに、途中で手順のいずれかに障害が発生した場合は、エラー処理を追加し、成功した手順を戻さなければなりません。

宣言型アプローチでは、スクリプトを何回実行しようと、最終的なインフラストラクチャーは同じです。最初に環境をプロビジョンし、その後でもう一度スクリプトを実行すると、環境が変化していないことを確認できます。

Infrastructure as Codeにおける異なるアプローチを理解することは非常に重要です。ただし私は、大抵は宣言型アプローチを選択します。

alt

[DevOps]

次はDevOpsについて説明します。私たちはDevOpsの重要性については理解しています。アプリケーションを開発する場合は、まずコードを記述します。次に、そのコードが実際に動作するかどうかテストします。そしてコードを本番にプッシュします。その後、すべてのプロセスが常時稼働し反復可能であることを確認します。

alt

世間には優れたアジャイルDevOpsフローを確立しているチームがあります。しかし彼らはレガシー・インフラストラクチャーを使用しているため、新しいVMを構成するたびにチケットをオープンする必要があります。その原因はVMが稼働しているインフラストラクチャーにあります。これがチームの進歩の妨げになっています。

Infrastructure as Codeがサポートされれば、コードと同等の品質でインフラストラクチャーを運用できます。これにはバージョン管理なども含まれます。基本的に、インフラストラクチャーが変更されたときには、それを追跡する必要がありますInfrastructure as Codeは自動化に最も適したアプローチです。

[イミュータブル・インフラストラクチャー]

最後にイミュータブルと、ミュータブル・インフラストラクチャーについてお話しします。 イミュータブル・インフラストラクチャーとは、修正、変更できないインフラストラクチャーです。このインフラストラクチャーを変更することはできません。

これは一見短所のように思えます。インフラストラクチャー・アーキテクチャーに対する変更可能なアプローチの例を通して詳しく見ていきましょう。

アプリケーションを開発しており、データベースが必要であると判断したとします。そのために開発環境でスクリプトを実行し、VPC内にデータベースを配置します。

alt

これは上手くいきました。そこでこのスクリプトを所有しているすべての環境で実行することにしました。全体の99%は正しく動作しましたが、一部で障害が発生し、不安定な状態です。

alt

詳しく見ていきましょう。私たちはバージョン1をバージョン2に移そうとしています。バージョン1を有効化するためのインフラストラクチャー・コードがあり、それをこのカスタム・スクリプトを実行してバージョン2に移しました。

alt

そこで発生するのが構成ドリフトや環境ドリフトと呼ばれる状態です。既存の環境が、自動化で使用する環境と一致しなくなります。

そこでこの障害状態をデバッグし、環境全体を破棄し、バージョン1を再デプロイしてスクリプトを実行する必要があります。初めの2、3回であれば問題はないかもしれませんが、規模が大きくなると保守作業がきわめて複雑になります。

イミュータブル・インフラストラクチャー・アプローチと、インフラストラクチャー自動化を採用した場合は、インフラストラクチャーを変更するたびに、古い環境とは別にまったく新しい環境を構築します。どちらの環境も正しく動作することを確認したら、古いバージョンを破棄できます。

alt

同時に2つの環境を稼働させるので費用は少し高くなりますが、インフラストラクチャーを確実にスケーリングするにはこれがベスト・プラクティスです。

Infrastructure as Codeの概要をご覧いただきありがとうございました。