こんにちわ、mamohacyです。
前回のエントリで、AWS Outposts/Wavelength/LocalZones勉強会を開かせていただいたお話をしましたが、
上記登壇と並行して行ったAWSのソリューションアーキテクトの皆様とのQ&Aの中で、低遅延３兄弟の仕様が徐々に明らかになってきました。その中で今回は特に私が注目していたOutpostsについてお話ししたいと思います。
AWS Outpostsはマルチテナントユースに向いていない？
もともと、我々が想定していたAWS Outpostsの活用方法は、我々が契約したOutpostsをユーザーごとに環境をセパレートして使う、いわゆる「マルチテナント（マルチアカウント）ユース」でした。
これは、単体としてのOutpostsが契約条件が非常に厳しい（３年縛り必須/契約期間中の移設不可/非常に高価）ことや、Outpostsの設置条件を満たすことのできるデータセンターやサーバルームを維持していくことが、大きなバジェットを持てないにユーザーとって、Outposts利用への大きなブロッカーになってしまうのではないか？という想定のもと考えたものでした。
そこで我々は、自社で活用するOutpostsを代表者として契約し、それを自社内の別のユーザー（アカウント）にマルチテナント利用させるようなイメージで導入できないか？ということを考えていました。
しかしAWSサイドとのQ&Aを重ねていくうち、いまのAWS Outpostsには、自社内の統合された環境としてOutpostsを複数の社内ユーザーから活用させることは想定されていても、上記のように「サービススライシング」するような形でのマルチテナントのユースケースは想定されていないことが徐々に分かってきました。
AWS Outposts マルチアカウント利用に係るあれこれ
前述の勉強会で発表した以降、我々が把握できたAWS Outpostsのサービス仕様のうち、主にマルチアカウント運用にかかるもので影響が大きそうなものをピックアップしてみます(※2020年3月1日時点）
ここでは便宜的にOutpostsの契約を行ったユーザーを「親アカウント」、このOutpostsを利用しようとする複数のユーザーを「子アカウント」と呼ぶことにします。
● Outpostsを複数アカウントで利用するためにはOrganizations配下に入る必要がある
Outpostsを複数のアカウント(IAMユーザーではなくAWSのアカウント自身）で共用するには、Organizationの親アカウントでOutpostsを契約し、Organizationsから発行したり外から取り込んだりした「Org 配下の子アカウント」でなければ利用ができません。
Private Linkのように、まったく無関係のアカウント同士であっても相互に信頼関係を結ぶことで共有できたりしそうなのですが、現時点ではまだそれができないようです。
● 子アカウント側からは通常のAWSのAZのようには使うことができない
そもそもマルチアカウント利用を想定に入れていないため、子アカウントから見ると通常時のような、あたかも自分のAZが増えたような使い方にはならないようです。
具体的にはOutpostsを保有する親アカウントでAWS RAM(Resource Access Manager)というサービスを使い、あらかじめ準備された特定のSubnetを、子アカウントに向けて「共有」して初めて使えるイメージになります。
もちろん親アカウント単体で使う場合には当初の想定通りAZが増えたような見え方になりますが、マルチアカウント利用の場合は運用上の工夫が必要になります。
● Outpostsで選択できるインスタンスタイプには大きな制約がある
たとえば最小構成のSKUである「OR-L8IF4WF」の場合、vCPUはm5.12xlargeのファミリですが、このSKUの場合1ラックに収容される物理サーバは2台だそうで、この中から2種類を選び、固定させて使う仕様とのことです。
ぱっと見、上記の例でいえばm5.12xlargeの中をユーザーが任意で自由に分割してインスタンスを立てられそうなものですが、そういうことはできない、ということです。仮に親アカウントがm5.xlargeとm5.8xlargeの2種類で設定していたら、子アカウントではこの２種類からしかインスタンスタイプを選べない、ということになります。より多くのインスタンスタイプを選べるようにしたければ、より大きなSKUを選んだり、導入台数を増やすしかありません。
この固定設定は親アカウント側で後から変更することもできるそうですが、その場合もいったん現在のリソースを全部退避させてから変更→リブートの作業が必要で、おいそれと変更することはできないと想定されます。
● Outpostsの側のリソース配分をサービス毎に既定しておくことはできない
Outposts上にあるvCPUを、これはEC2用、これはRDS用、これはEKS用などにあらかじめ分けて確保しておくことはできません。逆に言うとスケーラビリティや用途についてもかなり厳格に管理する必要があるということで、このあたりはOutposts特有の「オンプレ的な運用ポイント」になるかと思います。
● 現在のRDS for OutpostsはMulti-AZ構成に対応していない
前回のre:InventにてpreviewがアナウンスされたRDS for Outpostsですが、こちらはあくまでもSingle-AZでの利用のみサポートしています。仮にOutpostsを2台購入したとしても組めませんし、クラウド側と組合せて構成することもできません。
まだPreviewですので過度な期待は禁物ですが、当面の間はon EC2でDBMSを構築して、必要なH/A構成を組んだり、RDSがMulti−AZに非対応だった頃のような対策を施す必要があると思います。ただし繰り返しますがOutpostsは事実上オンプレミスのハードウェアなので、オンプレミスと同等のハードウェア冗長やネットワーク冗長、局舎冗長などをサービスのSLAに応じて考慮しなければなりません。
● Outpostsの購入にあたっては、AWSとの直接契約が必要
通常のAWSリセラーからの購入はできないため、導入を考えている企業がもしリセラー経由でAWSアカウントを調達している場合、それとは別にAWS側との直接契約アカウントを作る必要があります。
● エンタープライズサポートの契約が必須
さらに直接契約に加え、エンタープライズレベルのサポート契約が必須となります。つまり$15000/月あるいは全体費用の10%のどちらか高いほうを支払うことになります。Outpostsは3年間縛りの契約条件があるので、この費用発生は３年間続くことになります。
またリザーブドインスタンスをAll Upfrontで契約したことがある人なら経験があるかもしれませんが、Outpostsの契約費用も高額なためこれをAll Upfrontで払う場合は「どちらか高い方」の10%側にひっかかり、確実にその月のエンタープライズサポートの費用が跳ね上がることも忘れてはいけません。
ざっと計算してもこれだけで6000万円前後の費用が発生することになります。すでにエンタープライズサポート契約を結んでいるような大規模利用ユーザーにはあまり影響のない話かもしれませんが、やはり単発でOutpostsを使いたい一般ユーザーにとってはかなり敷居が高い条件と言えます。
● マルチテナント利用向けの課金按分機能はまだない
自社内での部門共有利用はもちろん、分割リセールを考えた場合でも、子アカウントへOutposts内のリソース利用に応じた費用請求を発生させたいと思いますが、現時点でその機能はありません。
発生する利用費用の按分についてはCloudWatchやBillingInfoなどのメトリクスを駆使して、自前で作りこむ必要があります。このあたりは普段シングルアカウントでIAMで利用部門を分けているような運用をされている方であればすでに作られている方もいるかもしれませんね。
あらためて問う「AWS Outpostsの存在価値」
以上のことからわかるように、やはりAWS Outpostsは当初の公式アナウンスどおり「低レイテンシの実現」を目的としたサービスであり、その特徴からOutposts上に構築されたサービスを利用するユーザーのすぐ近くに設置する必要があります。対抗となるノードは人間であってもシステムであっても良いのですが、いずれにしても「多種多様なユースケースで不特定多数の人がサービスを構築する」目的には向いていません。
あくまで、そのシステムの抱える課題が「レスポンス遅延」や「インタラクティブなクラウド利用が難しい立地条件」にあり、かつバックエンド／フロントエンドの大半がAWSで構築されているようなシステム・案件にはジャストフィットでマッチするでしょう。しかし付帯設備がAWSでないのに低レイテンシを実現する目的「だけ」にAWS Outpostsを導入する価値は個人的には低いと私は考えます。Outpostsとはいえマネージドコンソールはクラウド側からアクセスする必要がありますし、その機能を最大化するためにはリージョン側にあるクラウドサービスと組合せて使うことが必要だからです。
AWS Outpostsを導入したがために、システム全体の運用コストやスケーラビリティ、ポータビリティが下がってしまうようであれば本末転倒です。「それでもいいから低レイテンシを実現したいんだ」というのであれば、むしろOutposts以外のプロダクトも選択肢に入れて慎重に比較検討すべきです。AWS OutpostsはAWSのプロダクトが使えたり、AWSからコントロールできるとうメリットはありますが、それ以外の点においてはオンプレミスの設備と殆ど同じである、ということを忘れてはいけません。
Outpostsの共用利用ではメリットは出せないのか？
では、上記以外の目的で、社内でOutpostsを契約し社内の複数の利用部門で活用するメリットはあるでしょうか？
Outpostsには、「オンプレミス側とAWS側、２つのネットワーク経路が存在できる」ということは勉強会でもお話しました。そして子アカウントが自由にAZを使えない代わりに、「Org配下のアカウントむけであればOutposts内に親アカウントが作ったSubnetを子アカウントに共有させることができる」という仕様も判明しました。
この特徴を活かして、私が思いついたユースケースは下記の３つです。
既にAWS上に構築済みのシステムから、統合的かつ安全に社内のシステムにアクセスできる経路として使う
オンプレミス側にあるサービスに依存するような共通機能をOutposts上に作り、これをAWS側のシステムに共有して使わせる
オンプレミス側にあるデータをAWS側にアップロードする前の事前処理やクラウド側からオンプレ側への復号処理などを担う
いずれも、低レイテンシとは異なるユースケースですが、こういった統合機能・共通機能の一部をOutpostsで実現していくのはアリではないでしょうか。
もちろんこれらの設備はオンプレミスにサーバを立てて自前構築することもできるでしょう。既にそうやって中間レイヤーを実現している企業もきっと少なくないはずです。しかしすでに非常に多くのシステムがAWS上に作られていて、それらのガバナンス機能もAWS上の別アカウントで実現しているような企業では、こういうオンプレとクラウドの間に入る設備をOutpostsで作ることは、運用上・構築上のメリットはきっと大きいはずです。もちろん、決して安い買い物ではありませんから、コストとのトレードオフは十分に考慮しなければなりませんが。
まとめ
- 社内にOutposts基盤サービスを作り自社内の利用部門に共同利用させるのはハードルが高そう。(やってやれない事はないが）
- 同様のサービスを外販するリセラーサービスも今の所登場する可能性は低い(初期コスト＋運用コストがかかりすぎる）
- OutpostsをIT部門が契約し、クラウドとオンプレとの中間レイヤーとして機能を構築し利用部門に使わせるのはアリ
発表当初、私が勝手に意気込んでいた期待からは少しズレてしまいましたが、これはOutpostsのプロダクトが悪いわけでもコンセプトが悪いわけでもなく、そもそも私が考えていたようなユースケースが彼らのMVPの中に含まれていなかった、というだけのことです。言い換えれば、過度の期待によって明らかになっていなかった仕様を自分の都合の良いように解釈してしまっていた、と言ってもいいのかもしれません。
Outpostsも他のAWSサービスと同様に、ユーザーから同様のニーズが沢山上げられることがあれば、追加・改善されていくものと思われます。いちOutpostsファンとしてAWSに対して精力的にニーズをインプットしつつも、今後に期待してアップデートを待ちたいと思います。
