オンプレにクラウドサービスを導入できる「AWS Outposts」　IaCでわかった、CDKとTerraformのメリット・デメリット

自己紹介と本日のアジェンダ

福田優真氏：本日は、「AWS OutpostsをAWS CDKで管理する話」について、NTTコミュニケーションズの福田が発表します。

本日の目次です。まず自己紹介をしたあと、扱うサービスである「AWS Outposts」について紹介します。今回、このサービスでIaC（Infrastructure as Code）を検証した結果を報告したいので、IaCする方向について「CDK」と「Terraform」の2つを挙げ、最後にまとめというかたちで終わろうと思います。よろしくお願いします。

自己紹介です。福田優真と申します。NTTコミュニケーションズのイノベーションセンターに所属しています。主にクラウド周りをやっていて、マルチクラウドやハイブリッドクラウドを検証しています。

宣伝なんですが、先日NTTコミュニケーションズでOutpostsを扱ったというニュースがリリースされました。またOutpostsをIaCしたという話です。今回取り扱う内容についてブログを書きましたので、ぜひともご覧ください。

AWS Outpostsとは何か？

本題に入ります。今回の内容を要約すると「AWS OutpostsをIaCする話」ですが、「AWS Outpostsって何？」という方もいると思うので紹介します。

AWS Outpostsは、AWSの出すハイブリッドクラウド製品です。ハイブリッドクラウドという言葉に馴染みのない方もいると思いますが、オンプレミスにクラウドサービスを導入するためのソリューションです。

「Azure」「GCP」「AWS」などで展開されており、各社競い合ってパイを奪い合っているような状況です。Azureであれば「Stack Hub」や「HCI」、GCPであれば「Anthos」のほか、最近では「Distributed Cloud」というものが出てきました。今回AWSから紹介するOutpostsは、ハイブリッドクラウド製品として出ています。ハイブリッドクラウドの特徴として、データをパブリックな場所に流さなくてもクラウドサービスを利用できる点があります。

例えば、工場内でデータを留めておきたい時に、今まではクラウドサービスをパブリックネットワークに通さないと使えなかったのが、使えるようになるという製品です。従来のクラウドサービスであれば、先ほど言ったように、パブリックネットワークを通して「Lambda」や「EC2」や「EKS」を触っていたと思いますが、ハイブリッドクラウドを導入すると、オンプレ側にEC2などを持ってきて触ることができるようになります。

つまり、今までパブリッククラウドを通してサービスを触らなければいけない状況から一変して、オンプレ内でクラウドサービスにも触れる状況になってきたと言えそうです。

パブリックなAWSと変わらない体験を提供してくれる

実際にAWSが出している、ハイブリッドクラウド製品であるOutpostsについてより詳しく解説します。

（スライドを指して）こちらの製品は、AWSのサブセットが提供されており、EC2やEKS、ALB、S3、RDSなどが、その内部に載るようになっています。AWS Outpostsの特徴は、パブリックなAWSと変わらない体験を提供してくれるところです。UIやUXがPublic AWSのものと統合されているので、ほかのAWSサービスと変わらないかたちでOutpostsを管理したり、Outpostsに載るサービスやリソースなどを管理したりできます。

また、シームレスにパブリックなAWSのリソースと連携することも可能です。一部サービスがパブリッククラウド上にあるので、サービスではそちらを使って、EC2などはOutpostsに留めておくようなことも連携して利用可能です。

現在は、42Uラック製品と1U/2Uサーバタイプの製品が販売されていますが、今回は42Uラックを試したので、そちらのIaCなどについていろいろと解説できると思います。

先ほども言いましたが、UI/UXはほかのAWSサービスと変わりません。実際にマネジメントコンソールからも見せたいのですが、OutpostsをほかのEC2インスタンスと同じように管理できるし、Outposts上のサブネットなどもマネジメントコンソールから同じように操作することが可能です。Outpostsに載るリソースやOutpostsがPublic AWSと分離されていることはなく、AWS上のマネジメントコンソール上で一括して管理できます。

（スライドを指して）AWS Outpostsを実際にデプロイするとどのようなアーキテクチャ図になるのかを、見てもらいます。

Outposts自体はAZ（アベイラビリティゾーン）の1つにひもづくようになっています。コーポレートデータセンターの中にOutpostsをデプロイすると、AWS Cloudのいずれかのリージョンの中にひもづけられたAZがオンプレに拡張されるようなイメージです。

サブネットなどはOutpostsの上に載せることができ、同じようにオンプレ内にサブネットを展開できるようになっています。なので、基本的にAZレベルを意識してOutpostsを操作する必要があるということだけ覚えておいてください。実際、Outpostsはスライドのようなラックタイプで、小さめの白い筐体です。42Uのわりにはけっこうすっきりしたイメージですね。これはAWSの公式から画像を持ってきました。

AWS Outpostsのユースケース

Outpostsには実際にどのようなユースケースがあるのかについて見ていきます。まず、低レイテンシーなコンピューティングが可能です。Public AWSよりも近いところでオンプレ内に設置してクラウドサービスを利用するので、パブリックネットワークを通さなくてよくなり、その分だけレイテンシーが改善します。なので、レイテンシーの要件が厳しくてクラウドサービスを利用できないところでも導入が可能です。

また、ローカルなデータを処理できるので、一度パブリック上にデータを外出しする必要がありません。データを外出しできない環境でも導入が可能です。昨今であれば、データレジデンシー（データを特定の地域に留めておかなければならない状況）、例えばEU圏内に留めておかなければならない状況もあると思いますが、そのような状況でもOutpostsをデプロイするだけで、その場所にデータを留めつつクラウドサービスを利用することが可能です。

また、オンプレ環境のモダナイズとして利用することも可能です。オンプレのネットワーク内に設置することが可能なので、いきなりPublic AWS上にすべてを持っていく前段として、オンプレ内を共有しつつネットワークだけをクラウドサービスに徐々に移行していくというようなことも、ユースケースとして挙げられます。

IaC（Infrastructure as Code）の概念とメリット

ここまでOutpostsについて話しましたが、今回はこれをIaCした結果について報告します。

IaCをご存じない方もいると思うので最初に簡単に解説しますが、「Infrastructure as Code」の略です。インフラをコードによって定義・管理するという概念です。

インフラ構築をコード化するものなので、今まで手作業で「MySQL」をデプロイしていたのを減らして、コードで定義してコードを書いた状態でデプロイできるのがメリットです。設定値などもコードに書いておけるので、今まで手作業でコマンドを叩いて設定していた作業を減らすことが可能です。インフラ構築のノウハウはコードに表れるので、構築者だけが知っている情報という暗黙知を減らすことも可能です。

また、単にインフラ定義をコードで書いているだけなので、テストをその上でモックすることもできます。いちいち自分で機器を設定して動作確認をしなくても、テストを書いてテストを走らせて、実際にきちんと構築されるかを確認することができます。

また、コード化されるので、CI/CDでいろいろと自動化できる点もメリットです。さらに、コードによっては関数化していると抽象化できるので、例えば設定値がほんの少し違うものも差異を吸収して、その設定値だけを関数の引数とすることで抽象化できます。こうすることで、いろいろなものを共通化でき、環境ごとにデプロイする際の工数を圧縮することが可能です。IaCにはこのようなメリットがたくさんあります。

AWS CDK（AWS Cloud Development Kit）の概要

AWSでIaCするにあたっては、現状は「CloudFormation」のほか、「AWS CDK」とCloudFormationを組み合わせたもの、さらに「Terraform」の2つが主流かと思います。

今回は、この2つをこちらで検証したので、その内容について発表します。ご存じない方もいると思うので、まずは、AWS CDKやTerraformがどんなものかについて解説します。

AWS CDKは「AWS Cloud Development Kit」の略です。これ自体はApache License 2.0で配布されているOSSなので、条件を満たせばフリーで利用可能です。汎用プログラミング言語でインフラを定義するもので、CloudFormationをバックエンドとして、そこを通してインフラを管理したりプロビジョニングしたりするフレームワークです。

CloudFormationをご存じない方もいるかもしれませんが、これはJSONやYAMLなどでAWSリソース群を管理するAWSサービスです。設定値やどのようなリソースをデプロイするのかを、JSONやYAMLで書いてプロビジョニングしてくれます。

実際に、CDKで使える言語は、TypeScriptやJavaやC#など、現在一般で広く使われているプログラミング言語です。汎用プログラミング言語を使うので、これらの抽象化力によってコードがかなり短く抑えられ、かなり直感的に、どのようなリソースが定義されているかが把握しやすくなっています。

（スライドを指して）実際にTypeScriptで書いたコードの例です。このようにサブネットの定義を書いて、VPCにそのサブネットの定義を渡してデプロイしてあげるというコードです。小さいので具体的に四角の枠で囲って、説明します。

オレンジの四角の中がサブネットの定義です。パブリックネットワーク（パブリックサブネット）にNATゲートウェイを置いて、NATゲートウェイへルーティングするサブネットはこういうふうに作る、と定義したりとか。

あとは、完全に隔離された閉域ネットワーク。こういう名前で定義してと四角枠の中に書いて、最後にVPCを定義しなければいけないので、それらのサブネットを持つVPCを定義するというのをオレンジの四角枠の中で行っています。

かなり短くなりますが、これをCloudFormationで書くと170行程度になって見えません。

カスタムリソースの作り方

具体的にどのへんが先ほど説明した部分にあたるかを見ていきます。上の小さなオレンジの枠の中がVPCの定義で、それ以外がサブネットやらNATゲートウェイやらインターネットゲートウェイやらを定義している部分です。一部抜き出すと、オレンジの枠の中がサブネットの定義になっています。

このように、CloudFormationで書くとかなり長くなるものがAWS CDKを使うと短くなるというメリットがわかっていただけたと思います。

現状では、CloudFormationで提供されていないリソースもいくつかあります。新サービスなどがあると、CloudFormation側にはまだポーティングされていない状況があって、そういうものを管理するためのフレームワークがカスタムリソースです。CloudFormationで提供されていないリソースを無理やりCloudFormationで管理するためのフレームワークです。

Outpostsも、現在一部のリソースがCloudFormationで管理できないので、今回はこちらを利用しています。

具体的に、カスタムリソースをどう作っていくのか。リソースの作成や更新、削除の時にLambdaがフックするようになっており、このLambda関数にいろいろなリソースの状態を定義すると、そのLambda関数としてリソースが管理されるようになっています。

実際に、Lambdaフックをどのように実装していくのかを軽く見ていきます。このように、作成や更新や削除が来たよと、イベントが来るので、それらをハンドルしてリソースを作ると、例えばcreateHandlerの中でリソースを作り、updateHandlerの中で更新します。

Terraformの概要

ここまではAWS CDKについて解説してきましたが、次はTerraformについて解説します。Terraform自体はHashiCorpが開発するOSSで、AWS CDKと同じようにIaCを実現するものです。Apacheではなくて、Mozilla Public License 2.0です。これも同じように条件を満たせばフリーで使用可能です。AWS CDKとは違い、マルチクラウドをサポートしており、GCPやAzureなどのTerraformで一括して扱えるようになっています。

ただし、汎用プログラミング言語ではなく、HashiCorp Configuration Language（略してHCL）を使ってインフラを定義していきます。

Terraformの特徴ですが、AWS APIなどとクラウド上で提供されているAPIと比較的リソースが1対1で対応しており、多少コードが長くなりがちです。HCLもDSLなので、ループなどはできますが、抽象化力がそれほど高くないので、どうしてもコードが長くなってしまいます。

（スライドを指して）Terraformで、先ほどのAWS CDKで定義したVPCとサブネットを同じように定義した例です。90行程度のコードです。

VPCだけ見ると、このようにVPC、cidr_block、HCLを定義します。ほかはすべてサブネットなどの定義ですが、一部抜粋するとサブネットはこういうかたちで作ると書きます。

AWS CDKでIaCした結果

ここまで、IaCで使用するツールなどのフレームワークについて解説しました。次に、実際にOutpostsをIaCする話に移ります。今回はCDKとTerraformの2つを使って検証しました。時間の関係上、具体的なコードは割愛しますが、注意点について共有します。

まず、AWS CDKでIaCした結果について。サブネットがOutpostsでデプロイできるようになっていますが、こちらはデプロイするところまではサポート済みです。オンプレミスからAWSリソースに接続するための、CoIPというIPアドレスを提供できますが、これをパブリックIPと同じように自動的にコンポーネントにつけられる設定があります。

CDK以前に、そもそもCloudFormationに対応していないので、カスタムリソースで定義する必要があります。それ以外に関してはサポートされているので、特にカスタムリソースを使ってがんばる必要はありません。EBS Volumeに関してもサポートされているので、特に気にせずCDKでも利用できます。

EC2インスタンスもサブネット上にデプロイするだけです。実は、特に定義しないでOutposts上にあるサブネットにデプロイする指令をAWS CDKに書いておけば、自動的に載るようになっています。

root volumeとなるEBS Volume自体も、勝手にOutposts上に載るようになっているので、特になにもしなくてもそのままサポートされている状況です。

ALBは少しやっかいです。Outposts上に載せるという点では、そもそもCDK以前にCloudFormationでもサポートされていなかったようなので、全部自前でカスタムリソースを使って管理する必要があります。

S3は、Outpostsに載せるとAWS側では「S3 on Outposts」という名前になっているようですが、CloudFormation、CDKですでにサポート済みです。ただ、CDKでは、今使えるライブラリ自体がプレビュー段階にあるので、場合によってはバグを踏む可能性があることを覚えておいてもらう必要があります。

ただ、私が試したところ文句なく使えているので、相当トリッキーなことをしない限りは、バグを踏むことはないと思います。

TerraformでIaCした結果

続いて、TerraformでIaCした結果について共有します。

TerraformはCDKと違って、すでにサブネットのEBS Volume、サブネットにCoIPつけることに関してもサポート済みです。EC2インスタンスは特になにもしなくていいので、サポートはされていますが、特筆すべき点として、すでにTerraformはALBをサポート済みで、Outposts上でデプロイする際にはほとんどなんでもできる状況になっています。

S3 on Outpostsもサポート済みなので、TerraformはCDKと違って、特になにもせずとも各種リソースをOutposts上に載せる、IaCすることが可能です。

AWS CDKとTerraformを比較

（スライドを指して）ここまでTerraformとCDKの話をしてきましたが、比較するため表にまとめました。CDKは、TypeScriptやJava、JavaScriptなどの比較的慣れてきた言語で触れますが、TerraformはHCLという独自のDSLに慣れる必要があります。

状態の管理方法について。CDKはCloudFormationを使って管理するので、AWS側にリソースの管理をしてもらえますが、Terraformはtfstateファイルで管理することになるので多少難しいです。ただ、ファイル自体はS3やTerraform Cloud、ローカルなどで管理できるので、自分の好みの方法を選べます。

コード量ですが、CDKを見ればおわかりのとおり、かなり少なく抑えることができます。ただTerraformは、HCLの汎用化などの問題があるのでCDKより多くなりがちです。

Outposts上に置くリソースを比較しました。○は完全にサポートされている、△は一部サポートされていない機能がある、×は完全にサポートされていない、を表しています。

CDKは、EC2 subnetやALBなどは、まだ多少難がある状況です。S3 on Outpostsに関しては、まだプレビュー段階であることを覚えておく必要があります。

Terraformは、今回触ったリソースに関しては一通り、特に問題なく触れます。どちらも一長一短あるのが現状です。

TerraformとCDKによる管理は一長一短

今回の発表のまとめに入ります。今回はOutpostsについて、AWSが出すハイブリッドクラウド製品であると紹介しました。OutpostsでIaCもできると言いましたが、Terraformはサポート済みのものが多い一方で、CDKはまだ一部のリソースがサポートされていないので、カスタムリソースを使って自前でがんばる必要があることを共有しました。

TerraformとCDKによる管理は、一長一短だと覚えておいてもらえればと思います。CDKはコード量を少なく抑えることができますが、新サービスへの対応には、まずCloudFormation、その次にAWS CDKという順序になっています。やはり新サービスなどへの対応に多少難がありますが、リソースの管理はAWS側でフルマネージドで行ってくれるので、そのへんが利点です。

一方、Terraformは、HCLが多少、APIに比較的1対1対応しているところがあって、コード量が大きくなりがちです。OSSなところもあって、新サービスへの対応が素早い点がメリットです。ただ、どうしてもtfstateの管理は難しいので、それが課題になりがちです。

以上で「OutpostsでIaCした」ことに関する共有を終わります。ご清聴ありがとうございました。