JAWS DAYS2014 「最強のAWSに」複数VPCでのベストプラクティス【RTC、宮崎）の資料です

1. (C) Recruit Technologies Co.,Ltd. All rights reserved.
JAWS DAYS 2014
「これで最強のAWSに」
複数VPCでのベストプラクティス
2014年3月15日
株式会社リクルート テクノロジーズ
宮崎 幸恵

2. ★本日のアジェンダ
 自己紹介＆リクルートグループの紹介
 AWS上で共通機能を作る
 AWSをオンプレとつなぐ
 まとめ

3. 宮崎 幸恵★
み や ざ き さ ち え
【所属】
株式会社リクルートテクノロジーズ
ITソリューション1部
全社向けのインフラ基盤を提供している部署です。
【仕事内容】
リクルート(当時）入社以来、全社向けのクラウド基盤
の設計・構築・利用推進と支援に取り組んでいます。
【好きなAWSサービス】
VPC、IAM、Direct Connect
もうすぐ入社丸3
年になります

4. 旅行
お稽古
時事
ﾌｧｯｼｮﾝ
飲食
「選択・意思決定・行動」を支援する
情報サービスの提供しています
進学
就職
結婚
転職
住宅購入
車購入
出産/育児
Life Event
ライフイベント
Life Style
ライフスタイル
ショッピング
★リクルートグループのサービス

5. リクルートキャリア
リクルートジョブズ
リクルートスタッフィング
リクルート住まいカンパニー
リクルートライフスタイル
リクルートマーケティングパートナーズ
スタッフサービス・ホールディングス
リクルートアドミニストレーション
リクルートコミュニケーションズ
事業会社
機能会社 インフラ部門
大規模プロジェクト推進部門
UI設計/SEO部門
ビッグデータ機能部門
テクノロジーR&D部門
事業・社内IT推進部門
リクルート
ホールディングス
クラウドチーム
主な
提供先
★リクルートテクノロジーズについて

6.  自己紹介＆リクルートグループの紹介
 AWS上で共通機能を作る
 AWSをオンプレとつなぐ
 まとめ

7. 今日は全くリクルートグループのサービスの
話はしません。。

8. 基本構成は1サイト＝1VPC ≒ 1アカウント
・
・
・
Elastic Load
Balancing
EC2 Instance
Web App
Server
VPC Subnet VPC Subnet
×
70以上….

9. この状態で
全サイトに共通機能を提供しようとすると、
NW構成が複雑になってしまいました…

10. どんな共通機能？

11. ログ収集サーバで各サーバの
システムログやアクセスログを集めて
S3に保管しています

12. ログ収集サーバ
利用者環境
共通基盤環境
S3
td-agent
ログ管理スクリプト
VPC間をVPNでつないでログを送っています
VPC Subnet
Elastic Load
Balancing
Web App
Server
VPC Subnet
td-agent

13. Zabbixでの監視を提供しています

14. Zabbix親サーバ
共通基盤環境
Elastic Load
Balancing
VPC間をVPNでつないで監視しています
VPC Subnet
Zabbix子①
VPC Subnet
Zabbix子②
Availability Zone Availability Zone
利用者環境
URL監視はイン
ターネットから Web App
Server
VPC Subnet
Zabbix-
agent
LocalIPでの監視
（死活、ポート、
プロセス等）

15. Zabbixとは別に、Cactiで
リソースが見える画面を提供しています

16. Cacti
CactiもVPNでつないでいます
VPC Subnet
GUI画面はここ
で提供
Elastic Load
Balancing
Web App
Server
VPC Subnet
snmp-
agent
共通基盤環境
利用者環境

17. ここまでの共通機能を全部記載すると
こうなります

18. 管理APIサーバ
VPC Subnet
ログ収集サーバ
Zabbixサーバ
Availability Zone
S3
Cactiサーバ
Web App
Server
これがVPCベストプラクティス...!!
Region
TOKYO
California
開発Zabbixサーバ

19. VPCをたくさん組みあわせ始めると、
ベストな気が全くしません。。

20.  自己紹介＆リクルートグループの紹介
 AWS上で共通機能を作る
 AWSをオンプレとつなぐ
 まとめ

21. 弊社の場合、Webサービスを提供しているインフ
ラと、社内業務に使うインフラは全く別になって
います
サービス系インフラDC
(オンプレ）
社内業務系インフラDC
(オンプレ）
別DC

22. AWSはサービス系インフラDCとはつなげています
管理APIサーバ
VPC Subnet
VPC Subnet
ログ収集サーバ
Cactiサーバ
Availability Zone
サービス系インフラDC
(オンプレ）
認証機能をオンプレ側
で共通利用

23. 業務で利用するシステムの場合、
業務ネットワークとAWSもつなぐ必要がで
てきたりします

24. AWSを社内業務系のインフラとも一つVPCをつなげて
みました
VPC Subnet
Availability Zone
社内業務系インフラ
(オンプレ）
社内業務で利用+インター
ネット直接接続はなし
ProxyメールGWNFS
VPN
Connection

25. しかし、サービス系インフラと
社内業務系インフラはIP体系が違うので、
共通提供機能を使おうとすると、

26. ・・・NATするしかないので、こうなりました
社内業務系インフラ
(オンプレ）
サービス系インフラDC
(オンプレ）
管理APIサーバ
VPC Subnet
ログ収集サーバ
Zabbixサーバ
Availability Zone
VPN
Connection
VPC Subnet
Availability Zone
ProxyメールGWNFS
VPN
Connection
NATでVPC間通信
サービス系インフ
ラのIP体系
業務系インフ
ラのIP体系

27. ここまでの全体図

28. サービス系イ
ンフラDC
(オンプレ）
管理APIサーバ
VPC Subnet
ログ収集サーバ
Zabbixサーバ
Availability Zone
VPN
Connection
Availability Zone
ProxyメールGWNFS
VPN
Connection
社内業務系イ
ンフラ
S3
Cactiサーバ
Web App
Server
VPN
Connection
これがVPCベストプラクティス...!!!

29. VPCをたくさん組みあわせ始めると、
やっぱりベストな気はまったくしないです。。

30. なぜベストな気がしないのか
理由１：各サーバへの通信経路がわけわからなく
なる(作った本人でさえ、数十個のVPCで限界）
理由２：VPCが違う≒アカウントが違う、のため
個別管理がとてもつらい
理由３：理由1,2の結果、何かで通信が途絶えた
ときに障害切り分け&影響範囲特定がとても大変
になる。管理上もしんどい。

31. もっとベストにするには
案１：そもそもVPC分けるのをやめる
→ 無理。管理とセキュリティの問題。
案２：VPC間通信をやめる
→ 各VPCに監視サーバとか作ればいけますが、
効率化を目指すには現実的ではないですね..

32. お願いVPC！お願いIAM！
お願い１：なんとかVPCを分ける数を減らす
→ せめて同じVPCでGUI画面上見えるインス
タンスを制限できるようにしてほしいのですが...
お願い２：なんとかVPCを分ける数を減らす
→ VPCを一回作った後の拡張が大変で数が増
えたりするので、VPCサブネットが柔軟に（とはい
いませんが多少変えられるように）なったらと思います...

33. お願いVPC！
お願い３：VPC間通信をシンプルに
→ 今はVPCごとにルーターのインスタンスが
いるのですが、GWの機能をもっとパワーアップ
してもらえば....ちょっとは(お金も）経路が減るか
もしれないです

34. これからの野望
AWS中心にいろいろなインフラと連携する
＝究極ハイブリッド！=複数VPC必須！！
=VPC（+付随する権限とかGW）の機能拡張
に期待！！！

35. ありがとうございました
リクルートテクノロジーズ