「AWS Outputs上で動くリソースをCDKでラクに管理したい」　ドキュメントやエラーと睨めっこしてわかった実装のポイント　

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

福田優真氏（以下、福田）：では「AWS Outposts上のリソースをCDKする」という話で、NTT Communications株式会社の福田が発表します。

目次です。まず自己紹介をして、そのあとにAWS Outpostsについてどんなものかお話しして、最後にAWS Outposts上で扱うリソースをCDKする方法について解説して、まとめに入ります。

自己紹介ですが、名前は福田優真です。NTT Communicationsのイノベーションセンターに勤めていて、ハイブリッドクラウドであったりマルチクラウドであったり、主にクラウド周りを担当しています。

今回取り扱っている元というか、ニュースリリースやNTT Com. から出ています。また、発表で扱う内容は弊社のエンジニアブログに書いてあるので、そちらを参照してもらえればと思います。

AWS Outputs上で動くリソースをCDKで管理した時の苦労

本題に入っていきます。今回は、先ほどから何度か言っていますが、AWS Outputs上で動くリソースをCDKで管理したいというのがあったので、それをやっていろいろとわかったことや、難しいところを共有できればと思います。

さっそく苦労した点についてちょっと共有したいと思います。Outpostsを触るにあたって、とにかくCloudFormationのサポートがあまりまだ手が回っていないところがありました。カスタムリソースで自分でガリガリとやっていかなきゃいけない部分がけっこうあります。

サポートをしていてもL1レベルだったりして、リソース上で扱うのはL2でもあったりはするんですが、デプロイ時に「このOutpostsにデプロイしてくれ」みたいなのが指定できなかったりして、まだちょっとL2レベルではいろいろとできない状態なので、L1でがんばらなきゃいけないところがあります。

こちらからもいろいろと触っているうちにわかってきたこととか、足りないところに関してはAWS側に適宜フィードバックしているので、もしかしたら今後、状況が変わる可能性はあるかもしれません。ただ、今はちょっとがんばらなきゃいけない感じです。

一部のリソースも、別のリソースを利用するのにいろいろとデプロイ単位を決めなきゃいけなかったりはするのですが、依存性があるようでないものもあります。そのデプロイ単位をどう切り分けるかは、けっこう最初に困ったところです。

また、AWS Outpostsに関してCDKでやった例がほとんどネットワーク上には転がっていませんでした。要はレファレンスの実装とかがあまりないので、自分でドキュメント、APIレファレンス、CDKコマンドから出てくるエラーメッセージなどとひたすら睨めっこして、解析して、「どうやって動かすんだろうな」と試したのは苦労した点です。

それ以外にも細々と苦労した点はけっこうあるんですが、大まかにこんなところに苦労しました。

AWS製ハイブリッドクラウド製品「AWS Outposts」

「AWS Outpostsってどんなものなの？」とわからない人もいると思うので、ちょっと解説します。

こちらはAWSが出すハイブリッドクラウド製品です。そもそも「ハイブリッドクラウド製品ってなんなの？」というのがあると思うので、ハイブリッドクラウドについて解説します。

オンプレミスにクラウドサービスを導入するためのソリューションです。要はオンプレ上でネットワークを外出しできず、そのせいでクラウドサービスが利用できないところに食い込んでいくサービスです。

AzureやGCPやAWSで用意されて、それぞれGoogle、Microsoft、AWSなどが今展開しています。Azureであれば、Stack HubやHCIが出ていて、GCPであればAnthos、最近であればDistributed Cloudなるものも出てきたらしいです。AWSも最近はOutpostsという、今回紹介するやつを出していて、今回はこれにフォーカスして話します。

ハイブリッドクラウドを入れることでパブリックな場所に流さなくていい、データをパブリックなネットワークを介さなくてもクラウドサービス利用ができるようになるところがけっこうな強みです。

こういうクラウド製品を導入しにくい場所、例えば工場だったり、データがちょっと出せない、オンプレじゃなきゃいけないところにいろいろと食い込んでいく製品です。

ハイブリッドクラウド製品を導入した時にどうなるか、概念図を見ていきたいと思います。今までであれば、雲で表すと、パブリックインターネットを介してオンプレから出て、AWS上のサービスAzureみたいな感じでした。

ハイブリッドクラウドサービスを入れると、これを一部オンプレ内に持ってきて、例えばEC2であったりS3であったりをオンプレ内のネットワークで完結して触ることができるようになります。引き続きパブリック上のS3であったりEC2であったりも触れるんですが、これの一部をオンプレ内に展開できるのがおもしろいところです。

今回は42U ラックで試した結果について解説

Outpostsについてもう少し詳しく解説します。AWSのすべてのセットではなくて、サブセットが提供されます。EC2とかEKSとかALBとかS3とか、必要なものは一通りOutposts上で動くようになっています。Outpostsの管理もOutposts上で動くリソースもそうなのですが、パブリックのAWSと変わらない体験を提供してくれます。あとで画像を見せますが、マネジメントコンソールから、いろいろと普通にいじれる感じになっています。

パブリックなAWSのリソースともシームレスに連携可能です。パブリック上のEC2からOutposts上のEBSをマウントして利用することも可能です。

今Outpostsには42U ラック製品と1U／2Uのサーバータイプの2つがあるのですが、今回N Com.では42U ラックを導入していて、そちらをいろいろと触ったので、42U ラックで解説していきたいと思います。

Outpostsの管理ですが、マネジメントコンソールからOutposts IDが割り振られていて、ここの上でOutposts関連の管理がいろいろとできます。Outposts上で動くリソースも、VPCマネジメントコンソールの他のパブリック上のものと同じように管理できます。

Outpostsをデプロイすると、どういうネットワーク構成になるかを見せます。オンプレ内にOutpostsを設置するのですが、Outposts自体は1つのAZにひもづいているので、AZがオンプレ内に拡張されるようなイメージになります。この拡張されたAZ内にOutposts上のプライベートサブネットを置いていったり、リソースを置いていったりします。

なので、Outpostsをいじる時は、たまにですがAZを意識しなければいけないことがあったりします。AZに関してはいろいろ注意が必要です。

実際に導入すると、どんなものがくるのか。AWS公式から引っ張ってきましたが、こういうけっこうこぢんまりした筐体が届いて、それをデータセンター内に入れて、ネットワークにつないで利用します。

AWS Outpostsのユースケース

「じゃあOutpostsって、どんなユースケースがあるの？」というところ。Outpostsのユースケースとして、まずオンプレ内に設置するので、低レイテンシなコンピューティングが実現できるところが大きいです。

Public AWSの場合は、やはりパブリックネットワークを通さなければいけないので、その分だけネットワークレイテンシが大きくなります。Outpostsであれば、そのままオンプレのネットワーク内に設置するので、パブリックネットワークを通さない分だけレイテンシを低く抑えることができます。なので、調べた限りではゲーム系とかでも使われたりしているらしいです。

他にもローカルなデータ処理が可能になります。オンプレ内に設置するので、AWSのクラウドサービスを利用しているんだけれども、外に出ないでローカルにデータ処理ができるのがもう1つのユースケースです。

また、近年ではEUなどで顕著ですが、データを特定の地域にとどめておけという法律があります。そういうデータレジデンシーの観点ですね。これもOutpostsを導入しておけば、S3もそうですが、データをデプロイ先にとどめておくことができるので、データレジデンシーの観点からユースケースがいろいろと出てくるところもあります。

あとは、オンプレ環境をいきなりクラウドに引っ張っていく場合、AWSもそうですが、AWS特有のネットワークを知らないといけないんですけども。その前段として、Outpostsを導入して、そこの中にEC2 Instanceを立てたりしてサーバーに持っていくみたいな、オンプレ環境のモダナイズの、クラウド移行の前段として利用されるケースも考えられると思います。Outpostsにはこういったユースケースが考えられるので、導入すればいろいろとおもしろいところが出てくると思います。

subnet、EBS Volume、ALB、S3 on OutpostsをCDKで管理

実際に、今回このOutposts上でいろいろなリソースをCDKで管理して動かしてみたので、ちょっとそれについてお話できればと思います。

何度も言いますが、Outposts上で動くリソースをどうしてもCDKで楽に管理したいし、TypeScriptで管理したいという思いがあって、今回これをいろいろガリガリとやってみたという感じです。

今回試したリソースはいくつかあるのですが、そのうち発表するリソースは、subnet、EBS Volume、ALB、S3 on Outpostsの4つです。S3とちょっと名前が違うのは、Outposts上に載るのは普通のS3なのですが、AWS側の資料を探していたらOutposts上に載せるものはS3 on Outpostsという別の名前がついているみたいだったので、これも呼称を合わせてS3 on Outpostsと記載しています。

試した結果ですが、一部カスタムリソースを使わなきゃいけないのと、L2のサポートがまだなので、CFnのL1とちょっと向き合わなければいけないのがつらいところです。

カスタムリソースとは何か

もしかするとほとんど触る機会がないので、カスタムリソースをご存じない方もいると思います。これについて解説していきたいと思います。

カスタムリソース自体は、CloudFormationが対応していないリソースを管理する仕組みです。CloudFormation上で、ある意味無理やりCloudFormationで管理されていないリソースを管理するための枠組みです。

これ自体は単純に、作成とか更新とか削除のライフサイクルをフックしてくれるLambdaを用意すればよくて、そのLambdaで、作成時にリソースを作る、更新する、削除するみたいなことを担当してあげればいいフレームワークになっています。

CDKでやる場合は、Lambdaを用意して、あとはprovider frameworkというAWSが提供するフレームワークに則ってボイラープレートを書くと、比較的楽にカスタムのリソースを管理できます。

コードの実装例

具体的にどういうLambdaを書くのかというと、こういう感じのコードです。作成のeventなのか、削除のeventなのか、更新のeventなのかが来るので、これを見て各ライフサイクルに合わせてリソースを操作します。例えばCreateHundlerの中にALBを作ってあげたりします。

CDK側ではどういうコードを書くか。先ほどのLambdaをlambda.Functionで作って、custom-resourcesというライブラリの中にあるproviderを使ってonEventHandlerに先ほどのLambdaを登録します。

最後にaws-cdk-libの直下にCustomResourceというリソースがあるので、こちらにprovider.serviceTokenというものをお決まりで登録する、というコードになっています。こんな感じです。

たまにLambdaにいろいろと引数を渡したいことがあると思いますが、aws-cdk-libの下にあるcustom-resourcesの中に、propertiesというプロパティがあって、こちらにオブジェクトでキーバリューを入れて指定すると、そのままオブジェクトがResource propertiesという名前でLambdaに渡ってくるので、それを使って引数処理をすることは可能です。

subnetとALBの2つでカスタムリソースが必要

今回のカスタムリソースは、subnetとALBの2つで使わなければいけません。subnetに関しては、実はデプロイを使わなくていいのですが、オンプレ上のネットワークからAWS Outpostsのリソースに接続する際に必要となるIPアドレス、顧客所有のIPを各種リソースに自動でつけるMapCustomerOwnedIpOnLaunchだったかな？　という設定をつけるのにL1すら対応していないので、ちょっとカスタムリソースでがんばらないといけないのが1つあります。

ALBも、Outposts上でAPI上はデプロイできるのですが、L1レベルでのサポートすらないので、こちらもカスタムリソースでがんばらなければいけないところがありました。

逆にS3 on OutpostsとEBS VolumeはL1でサポートをされているので、実はカスタムリソースは要らず楽ができます。ただS3 on Outpostsに関しては、ライブラリで見ると「プレビュー段階だよ」というのがつけられているので、バグを踏み抜く可能性もあるのかなという感じです。

（次回へつづく）