Tweet
Tweet

Slide 1

Slide 1 text

AWSネットワークリソースを サービスでマルチテナントに 提供するときのスケーラビリティ 2021/12/3 NW-JAWS 勉強会#8 @takipone 資料 : https://speakerdeck.com/takipone/nwjaws202112-takipone

Slide 2

Slide 2 text

誰 ● Ryuta Otaki @takipone ● Job : SA/BD@NTT East (Dec 2021-) ● Interest : Networking ● Favorite Services : Amazon Route 53, CloudFlare, Vercel

Slide 3

Slide 3 text

AWSネットワークリソース ● VPC ● VPCサブネット ● VPC IPAM [NEW] ● ルーティングテーブル ● ELB ● Elastic IP ● NATゲートウェイ ● Network Firewall ● VPCピアリング接続 ● Transit Gateway ● Cloud WAN [NEW] ● Site-to-Site VPN ● クライアントVPN ● Direct Connect ● Outbound転送

Slide 4

Slide 4 text

ネットワークがクラウドに載って変わ ることと変わらないこと 2019/09/17 NW-JAWS 勉強会#5 takipone 資料: https://speakerdeck.com/takipone/nwjaws201909-takipone 過去のスライド

Slide 5

Slide 5 text

まとめ • ネットワークがクラウドに載ることで、 ネットワークエンジニアはスケールする • 仮想ネットワークはクラウドとクライアントの境界 を曖昧にする • 仮想ネットワークはユーザー自身で作れる、 まだ世にないネットワークサービスを作っていき ましょう！ 過去のスライド

Slide 6

Slide 6 text

AWSのネットワークリソースを サービスに使う ☟ マネージドサービスの一種として ありがたく使わせていただくのだ

Slide 7

Slide 7 text

例 : SSL-VPNの実行環境をSaaSで提供(適当) VPC EC2 (VPNサー バー) RDS (DB) ELB (ロード バランサ) VPC EC2 (VPNサー バー) RDS (DB) ELB (ロード バランサ)

Slide 8

Slide 8 text

AWSにはAPIがある ● AWS SDK ● AWS Lambda ● CloudFormation ● Terraform オンラインの申し込みボタン 「ポチー」から 自動でスタック(システム一式)を デプロイ

Slide 9

Slide 9 text

AWSネットワークリソース ● VPC ● VPCサブネット ● VPC IPAM [NEW] ● ルーティングテーブル ● ELB ● Elastic IP ● NATゲートウェイ ● Network Firewall ● VPCピアリング接続 ● Transit Gateway ● Cloud WAN [NEW] ● Site-to-Site VPN ● クライアントVPN ● Direct Connect ● Outbound転送 使えそうな 自分で作る/運用するの しんどいなー。をお任せ Avoid再発明&開発工数

Slide 10

Slide 10 text

共有のための機能もある ● 共有VPC (サブネットの共有) ● VPCエンドポイントサービス (PrivateLink) ● Amazon EventBridgeパートナーイベントソース これらを利用するのがベスト

Slide 11

Slide 11 text

注意するべきはクオータ ( 1 ) ● ソフトリミット(上限緩和で増えるクオータ)と ハードリミット(サポートに泣きついても増えないクオータ)を チェック 上限緩和にはコツがあるので、 NW-JAWSの識者に聞こう！

Slide 12

Slide 12 text

注意するべきはクオータ ( 2 ) ● AWS Service Quotas コンソールで一覧 ● CloudWatchアラームで監視できる(とドキュメントには 書いてあるけど、本日時点でVPC周りで監視できるメトリクスは 0。みんなで機能要望を出そう！) ● ある日突然、クオータがめちゃくちゃ増えることもまれによくある

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

クオータに近づくのを抑止する ● ユーザーからはこちらの懐事情が見えないし、関心も無いので 有限なリソースをじゃぶじゃぶ使う。 ● 何とか食い止める施策を練る ○ サービスの値付けに反映する ○ 申請ベースのLimited Previewにしてユースケースの事前 審査を設ける

Slide 15

Slide 15 text

シングルテナント vs マルチテナント ● クオータはAWSアカウントごとに割り当てられる ○ AWSアカウントを顧客ごとに分けるシングルテナントだとク オータ管理の難易度はすごく下がる ○ Noisy(Too thick) Neighborの回避にも有効 ● 顧客のスケールに対応できるのはマルチテナント、シングルテ ナントで運用が破綻しないか ● サービスのビジネス側面とマッチするか精査して選択

Slide 16

Slide 16 text

まとめ ● VPCはじめAWSのネットワークリソースをサービス開発に活用 しよう ● VPCエンドポイントサービスなど共有機能がおすすめ ● クオータを把握して運用しよう ● マルチテナントとシングルテナントを選択する