Akamai Connected Cloud (Linode) メモ
voluntas概要
Akamai Connected Cloud (Linode) へ、自社サービス、開発環境を移行していってるので、メモ。
前提
- 自社製品は音声、映像、データを超低遅延で配信するミドルウェア
- 自社製品は Raft ベースの分散システム
- 自社製品はパッケージソフトウェアとして販売している
- 自社サービスは自社製品のクラウド版として提供している
- 自社製品の検証サービスは Akamai Connected Cloud へ移行済み
- 自社製品の商用サービスも Akamai Connected Cloud へ移行準備中
- Akamai Standard Support 契約済み
voluntasなぜ Akamai Connected Cloud (以降 Linode) を採用したのか
元々利用はしていた、ただ検証サービスでマルチクラウドの一部として使っていた程度。
ネットワーク品質
Akamai といえば CDN 、つまりネットワークに関して圧倒的な知見がある。
それに乗っかるのが一番良いと判断した。
DDoS 対策
Akamai はセキュリティにとても強い会社で、DDoS 対策がデフォルトで付いてきたりする。
ネットワークセキュリティは専門家に任せるのが一番と判断した。無料で利用できる。
ロードバランサー (NodeBalancers)
自社製品の WebSocket と、バックエンドの冗長化のためにマネージドのロードバランサーが必須だった。月 10 ドルで利用できる。IPv6 に対応。
サポート信頼性
以前利用していたあるサービスのサポート体験がとても良くなかった事があり、移行先はサポートの評価が高いサービスを採用したいと考えていた。特に障害発生時の対応を重視した。
そこで、Akamai を使い込んでいる友人に相談をしたところ「サポートの品質はどこのサービスよりも良い」と教えて貰い、さらに営業の方を紹介して貰えることになった。
おかげでスムーズに Akamai Standard Support が契約できた。契約後色々と問い合わせをさせていただいているが、回答速度、回答の質にとても満足している。
もしサービスが拡大した際は Enhanced Support SLA を検討できるのも大きい。
Egress 転送量価格
圧倒的な価格の安さで 1 GB で月 0.005 ドル、つまり 1 TB で月 5 ドル。もちろん Ingress は無料。
さらに、コンピュートインスタンスに Egress 転送量が付いてくる。一番安い月 5 ドルのインスタンスでも 1 TB 付いてくる。
このインスタンスに付いてくる Egress 転送量は Network Transfer Pool アカウント全体で共有される。自社製品は分散システムのため、多くの小さいサイズのインスタンスを起動するため、この仕組みと相性が良い。
クラウド全体での価格
価格もかなりありがたい金額。 AMD EPYC の Premium CPU (4C/8G) で月 86 ドル。自社製品は分散システムなので、このスペックで 50 ノード立てても月 4300 ドル、Egress 転送量は 1 インスタンスで 5 TB 付いてくるので、250 TB までは無料で利用できることになる。
たった月 4300 ドルで、合計 200C と 250 TB の Egress 転送量が手に入る。夢のようだ。弊社の分散システムとの相性がおかしいくらい良い。
多くの機能はいらない
自社製品をマネージドサービスとして提供するのがメインなので、多くの機能は不要。さらにできるだけ手弁当でやるという方針なので、シンプルなサービスであることが重要だった。
- コンピューティング
- ロードバランサー
- ブロックストレージ
- S3 互換オブジェクトストレージ
- プライベートネットワーク
- ファイアーウォール
データベースを将来的にはじめるらしいのでそれは使っていきたい。
Ansible 対応
自社ではデプロイに全て Ansible を利用しているため、Ansible に対応していることはとても重要。
VPC/VLAN
自社システムが分散システムということもあり、内部ネットワーク通信が大量に発生する。そのため Akamai Connected Cloud では VPC だけでなく VLAN が利用できるのはありがたかった。
多くのクラウドサービスと同様 VPC/VLAN 間の通信は転送量に含まれない。
また VPC は将来的に地域間データ転送に対応するとのことで、マルチリージョンでの分散システムを検討している自社との相性が良かった。
歴史が長いサービス
Linode 自体が 2003 年からのサービスで、Akamai が買収後も積極化的に改善されて行っている。
voluntas利用メモ
Placement Groups (BETA)
最近ベータ版として追加された機能に Placement Groups という機能があり、これがとても気に入っている。
この機能はコンピュートインスタンスを起動する際、ハードウェアやネットワーク障害が発生したときに影響をうけない用、異なる Failut Domain にインスタンスを起動してくれるようになります。
自社の分散システムではハードウェア障害が起きた際、分散システムを維持するためのノードが同時に落ちるのはサービスとしては致命的です。これが明示的に指定できるのは本当に良いです。
自社製品では分散システムを維持するために必要なノード数を 5 としています。例えば 50 ノードの分散システムを組む場合、維持するためのノード 5 と維持に影響しないノード 45 となります。
アンチアフィニティ: コンピュートインスタンスは異なるフォルトドメインに配置されますが、同じリージョン内にあります。この好ましいコンテナタイプは、高可用性モデルをよりよくサポートします。
厳格な（ベストプラクティス）: 好ましいコンテナに容量が不足しているか利用できない場合、配置グループにコンピュートインスタンスを追加することはできません。例えば、好ましいコンテナタイプがアンチアフィニティ（Anti-affinity）であると仮定します。同じホストにあるコンピュートインスタンスを追加しようとしたり、リージョン内でそのホストの外に容量がない場合、エラーが発生し、コンピュートインスタンスを追加することはできません。これにより、配置グループのコンプライアンスが維持され、好ましいコンテナタイプに適合するコンピュートインスタンスのみを選択できるようになります。
NodeBalancers (LB) の安定性
以前利用していたサービスの LB が WebSocket 利用時に不安定な挙動をするというのがあり、LB の安定性に不安があったため、色々試験をした結果、問題は全くないと判断した。長期間の常接続も問題無く動作した。
NodeBalancers (LB) の最大 10000 同時接続という制限
弊社の場合は常時接続部分を WebSocket から DataChannel へ通信を切り替える仕組みがあるため、ほとんど問題になることもないと考えている。
また、そもそも LB は弊社製品への接続のための URL を一本化するための利用しており、複数の URL をクライアントに提供する仕組みで解決できるため、ネガティブになるポイントはない。
ちなみに回避策もあるため、もし気になる方は Akamai へ問い合わせる事をお勧めする。
VLAN のドキュメントの少なさ
情報がかなり少ないので、ちょっとやっかい。とはいえ、ただ NIC が増えるだけではある。この辺りは Akamai のサポートに色々問い合わせをさせていただき、明確な回答を頂いた。とても助かった。
voluntas今後の要望
これらは既に Akamai 側に共有済みです
- NodeBalancers で出口だけでなく入口もプライベート IP に対応してほしい
- LB にプライベート IP を振ってほしい
- 最新の EPYC を提供してほしい
- ブロックストレージを SSD だけでなく HDD を提供してほしい
- Vultr が SSD の 1/4 の価格で HDD のブロックストレージを提供している
- 東京リージョンに Premium CPU を提供開始してほしい
- 東京リージョンに VPC を提供開始してほしい
- PostgreSQL のマネージドサービスを提供開始してほしい
- VPC の地域間データ転送を提供開始してほしい
- グローバル負荷分散サービスを提供開始してほしい