[レポート] NET323: Vanguard とブルームバーグは如何に PrivateLink を使いこなしたか #reinvent

開催中の AWS re:Invent 2018 会場より、本日（ 11/27 現地時間）行われた下記セッションをレポートします。

セッションタイトル

• NET323 How Vanguard and Bloomberg Use AWS PrivateLink

概要

セッション概要より抄訳：
Vangard と Bloombarg の両社はそれぞれ PrivateLink を使い、少数の大規模アカウントを多数の小規模アカウントへと移行させました。本セッションでは PrivateLink のユースケースとして3つのタイプを紹介します。

Vanguard and Bloomberg's use of AWS PrivateLink as they moved from a small number of large accounts to a large number of small accounts reduced blast radius at the management plane but introduced significant complexity at the network layer. In this session, we introduce the type of network segmentation that is required to implement a zero-trust network for a highly regulated financial investment company like Vanguard—one that adds additional complexity.

Speaker

• Ilya Epshteyn - Principal Solutions Architect, AWS
• Barry Sheward - Chief Enterprise Architect, Vanguard
• Cory Albert - Head of Cloud Strategy, Enterprise Data, Bloomberg LP

資料

動画

内容

AWSネットワークのおさらい

• VPCの中にAZがあってSubnetがある
• Public SubnetからはIGWで外へ
• Private SubnetからはNAT経由で外へ
• オンプレミスとはVPNやDirectConnectで接続
• VPC同士はVPC Peeringで接続
• AWSサービスのパブリックエンドポイントへはインターネット（IGW,NAT）経由で接続
• VPCエンドポイント

VPCエンドポイントのゲートウェイタイプ

• 制限事項 - S3とDynamoDBだけ
• オンプレからダイレクトにはアクセスできない
  • プロキシをセットアップすれば可能だが複雑
• AWSサービスでしか利用できない

VPC Peering

• 広帯域・双方向ネットワーク通信を念頭に置かれたデザイン
• マイクロサービスには向いていない
  • 125コネクション/VPCが限度
• CIDRアドレスレンジがかぶってはいけない

そこで AWS PrivateLinkですよ

• セキュアでスケーラブルなサービス共有モデル
• VPCとオンプレ両方にサービスを提供できる
• サービスオーナーはネットワークを複雑にせずにサービスコンセプトを展開できる
• 接続にあたってはサービスユーザとして登録させる

PrivateLink のユースケース 3パターン

• (現時点で) 18の AWS サービスを利用（EC2, Systems Manager, CloudWatch, KMS, IAM STS ...）
• 他の AWS アカウント / VPC とサービスを共有 -> Vanguard
• AWS パートナー / マーケットプレイス -> Bloombarg

PrivateLinkのアーキテクチャ

• サービス用の ENI の前に NLB を置く
• 相手側の VPC 内に VPC エンドポイントを置いて NLB に紐付ける
• CIDRはかぶっても良い（関係ない）
• EC2 でなくてもオンプレでも良い（ENI に紐付ける）

Key benefits

• 外部のサービスにプライベートIPアドレスで接続可能
• いくつかの信頼性の高いスケーラブルな技術を使ってアクセス可能：
  • AWSサービス
  • エンタープライズレベルのマイクロサービス
  • オンプレミスソリューション
• CIDRがかぶっても良い、管理すべきポイントを減らせる
• 接続は常に登録されたユーザと
• VPCまたはオンプレミス（DX, VPN）からアクセス可能
• AWSサービスによるサポートの範囲拡大

事例 1: Vangard

他の AWS アカウント / VPC とサービスを共有 -> Vanguard

• AWSと近いところにずっと本社がある（会場笑い

移行前

• 最初は凄くシンプルだった
• 最後に非常に複雑になった

• Production, Test, Development
• LOB (Line of Business, 事業部門)
• ESS (Enterprise Security Services, 情報セキュリティ部門)
• NAC (聞き取れず)
• DCS (Datacenter Service)

• 手動プロビジョニング
• 設定矛盾
• IPアドレスの枯渇（飢餓）

Vanguard cloud registory service (VCRS)

• AWS Organizations と PrivateLink で社内展開
• root アカウントに VCRS エンドポイントを作成、PrivateLink 経由で他アカウントから参照
• 他のサービスも PrivateLink で公開

今後の予定

• Ephemeral（一時的な）アカウント
  • The Three R’s of Enterprise Security の AWS アカウントへの適用
    • Rotate, Repave, Repair
  • Zero Access のサポート
    • アクセスがなければそれだけ安全である
• 目的に適合するアカウント
  • 特殊ケースに対応できるように
  • 標準的な構築基準
• 両方を CFn で

Bloombarg

AWS パートナー / マーケットプレイス -> Bloombarg

• 顧客へのサービス「B-PIPE」をPrivateLinkで実施
  • 導入事例 : Bloomberg B-Pipe
  • エンタープライズ ソリューション - Bloomberg Professional Services | Japan

B-PIPEは、スピード・標準化・信頼度・コスト効率の面で、すぐれたリアルタイム統合マーケットデータフィードです。ブルームバーグの高パフォーマンス技術とコンテンツが組み込まれたB-PIPEは、卓越した機能やデータカバレッジを提供します。 グローバルカバレッジと低遅延性に焦点を当て、世界の200以上の取引所と2500以上の情報提供社から得られるすべてのティックおよび取引情報を配信します。

要件

• 妥協のないオファーであること
  • コンテンツ
  • 提供データの量
  • 柔軟性
  • 遅延（レイテンシ）
• マネージドソリューションの継続利用
  • データパスのモニタリング
  • ソフトウェアアップグレード
  • ライセンス・利用許諾のマネジメント
• クラウド・オンプレ　その他 API の整合性

構成

• US East
• 10G DirectConnect
• B-PIPE サービスは EC2 上で起動
• NLB での提供、顧客は VPC エンドポイントで接続
• Route 53 での DNS もオプションで提供
• 一部顧客（アーリーアダプタ）にベータ提供

なぜPrivateLinkを採用したか

• セキュアで信頼性の高い接続性
• 顧客が B-PIPE へアクセスするために素早く設定できる
• 既存のメンテナンスアプローチが使えること
• 既存のモニタリングツールが顧客・運用チーム双方とも使えること

結果と今後

• 同時接続数　〜3,500ストリームでレイテンシを計測し既存システムと比較
  • 99パーセンタイルで差異 0 ms 以下
• B-PIPE インスタンスに疑似障害を発生させ、自動復旧を確認
  • 挙動に既存システムとの差異なし
• これから
  • GA を目指す
  • サーバーレスの適用範囲を広げる

所感

欧米では「社内で社内向けのシステムをきっちり作り込む」文化が浸透していて、そのため Service Catalog の利用が日本より浸透しているという話を聞いたことがありました。 PrivateLink もそのようなカテゴリかと勝手に思っていたので、今回 Vanguard の事例が聞けて大変興味深かったです。