不変のインフラストラクチャ：ネットワーク

ネットワークインフラストラクチャを扱う方なら、設定に「ほころび」が生じ、当初の構成からずれていく傾向があることをご存じでしょう。クラウドのオペレーティングシステム（OS）であり、インフラストラクチャに関する信頼できる唯一の情報源としてFugueを構築する目的の一つは、インフラストラクチャを正常な状態に保ち、このずれを防ぐことです。結局のところ、「信頼できるシステムは、その作成者が意図したことだけを実行する」のです。

これまで、コンピューティングインスタンスに生じる「ほころび」に焦点を当ててきましたが、この問題はネットワークなど、ほかのインフラストラクチャコンポーネントにも存在します。ネットワークの構成ドリフトは、デプロイや保守に手作業が伴う場合によく発生します。スプレッドシートの何百行にも及ぶネットワーク構成を、1行ずつ手作業でデプロイする現場を見たことがあります。アプリケーションが正常に動作しないときは、ポートやIPアドレス範囲を開放するために、担当者が直接手作業で変更するのが一般的な解決策です。

その結果、新しい構成が元のスプレッドシートに反映されないことがよくあります。一時的な修正が忘れられ、恒久的な変更になってしまうこともあります。アプリケーションに新しいサービスを追加する際には、さらに手作業が必要です。こうした手作業は、セキュリティグループのルールを誤って開放するなど、アプリケーションをセキュリティリスクにさらすだけでなく、ルールやルートを誤って削除した場合には、アプリケーションの大幅なダウンタイムを招くおそれもあります。

ネットワーク構成の課題は、手作業での実装をインフラストラクチャ自動化に置き換えるAWS CloudFormationなどのDevOpsツールやサービスによって、ある程度解決されてきました。この方法なら、ネットワーク構成を、制御されたドメイン固有言語（DSL）やテンプレートで管理できます。繰り返し適用でき、監査やテストも可能です。

しかし、こうしたツールの多くには限界があります。ネットワーク構成をデプロイするだけで、初回のデプロイ後は意図した状態を維持しません。これらのツールでデプロイした後に、ネットワークが手動で変更されると、その問題が明らかになります。最悪の場合、変更はそのまま放置されます。よくても、最初にデプロイしたルールだけが適用されます。

Fugueは、ネットワークの自動化と制御をさらに一歩進めます。デプロイ時に意図した状態へネットワークを常に戻すことを目指しています。構成で定義したルールが削除されると、Fugueが復元します。構成で定義されていない新しいルールがネットワークに追加されると、Fugueが削除します。

その仕組みを説明するために、AWSセキュリティグループを使った、短くても効果的な例を見てみましょう。

security-group web-elb-sg:
description:
'Allow port 80 from the world' ingress-rules:
{ 80: all-tcp } egress-rules:
{ 0-65535: all-tcp }security-group web-server-sg:
description:
'Allow port 80 from the web-elb-sg Security Group' ingress-rules:
{ 80: allow-from-web-elb } egress-rules:
{ 0-65535: all-tcp }rule allow-from-web-elb:
ip-protocol:
'tcp' groups:
[ web-elb-sg ]

上記のLudwigコードでは、web-server-sgセキュリティグループを定義しています。このグループでは、web-elb-sgからのポート80へのインバウンドトラフィックを許可しています。このコードをコンパイルして実行すると、Fugue Conductorは、構成で定義したセキュリティグループとルールがAWSアカウントにデプロイされるようにします。

しかし、Conductorの役割はそれだけではありません。EC2インスタンスの場合と同様に、Conductorは実行中の構成を、当初定義してコンパイルした内容と定期的に照合します（現在は10秒ごと）。ネットワークインフラストラクチャが構成内の内容と一致しない場合、当初の状態を保つために必要な変更をインフラストラクチャに適用します。

ネットワークに「ほころび」を生じさせて、Fugueの機能を試してみましょう。ここでは、善意はあるものの経験の浅いシステム管理者を演じます。稼働中のWebサーバーのログを確認しようとした、という設定です（導入されたばかりのログ管理システムには気づいていないものとします）。

AWS管理コンソールにログインし、0.0.0.0/0からのSSHを許可するセキュリティグループルールを追加します。以下の動画でご覧いただけるように、ルールを追加してから数秒以内にそのルールは削除され、セキュリティグループは元の構成に戻ります。

別の状況も考えてみましょう。金曜日の午後、善意のシステム管理者が週末に入る前にAWSアカウントのセキュリティルールを確認しようとしています。ここでは、Webサーバーへのポート80のインバウンドトラフィックを許可するセキュリティグループルールを、誤って削除してしまうシナリオを再現します。自分が何をしたか気づかないまま、ノートパソコンを閉じてパブへ向かいます。

一般的な環境では、この状況によってサイトが大規模に停止する可能性があります。しかし、このシナリオで発生するダウンタイムは最大でも10秒です。Conductorがチェックを行い、Ludwig構成で定義されたとおりにセキュリティグループルールをすばやく再作成します。

この機能は、セキュリティグループやルールだけに適用されるものではありません。Conductorは、VPCルート、ネットワークACL、インターネットゲートウェイ、サブネットなど、ほかのネットワーク構成も定義どおりの状態に保ちます。

構成の内容を変更したい場合はどうすればよいでしょうか？

実行中の構成を変更するのは簡単です。たとえば、インターネットからのポート443への通信を許可するルールをELBセキュリティグループに追加するとします。まず、変更内容が反映されるようにLudwig構成を編集します。

security-group web-elb-sg:
description:
'Allow port 80 and 443 from the world' ingress-rules:
{ 80: all-tcp, 443: all-tcp } egress-rules:
{ 0-65535: all-tcp }security-group web-server-sg: 
description:
'Allow port 80 from the web-elb-sg Security Group' ingress-rules:
{ 80: allow-from-web-elb } egress-rules:
{ 0-65535: all-tcp }rule allow-from-web-elb:
ip-protocol:
'tcp'
groups:
[ web-elb-sg ]

編集が完了したら、Fugue CLIで次のコマンドを実行します。

$ fugue load foo.lw$ fugue update foo.lw

Fugueのloadコマンドは、変更した構成をコンパイルしてS3にアップロードします。続いてFugueのupdateコマンドがConductorに通知し、S3から更新版を取得して、既存の実行中の構成に変更を適用します。

なぜこれが重要なのでしょうか？

毎週何時間もかけてネットワーク構成を手作業で保守・変更しても、「ほころび」は生じ続けます。従業員のリソースを賢く活用しているとは言えません。Fugueなら、インフラストラクチャコンポーネントのデプロイ、保守、更新を自動化し、確実に実行できます。Conductorに希望する内容を伝えるだけで、変更が適用され、その状態が維持されます。

Fugueを使えば、ネットワークを定義どおりの状態に保ちながら、デプロイ時間と継続的な保守の負担を軽減できます。Ludwig DSLは意図に基づき、繰り返し適用でき、適用状態を維持できるうえ、監査も可能です。そのため、ネットワーク構成が常に意図した状態に保たれているという確信を持って、アプリケーションを運用できます。

不変のネットワークインフラストラクチャを実現すれば、アプリケーションに求められる厳格な社内外のセキュリティ要件やコンプライアンス要件にも、わずか数行のコードで対応できます。