(C) Recruit Technologies Co.,Ltd. All rights reserved.

JAWS DAYS 2014 「これで最強のAWSに」

複数VPCでのベストプラクティス

2014年3月15日

株式会社リクルート テクノロジーズ 宮崎 幸恵

★本日のアジェンダ

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

宮崎 幸恵 ★ み や ざ き さ ち え

【所属】 株式会社リクルートテクノロジーズ ITソリューション1部 全社向けのインフラ基盤を提供している部署です。 【仕事内容】 リクルート(当時）入社以来、全社向けのクラウド基盤の設計・構築・利用推進と支援に取り組んでいます。

【好きなAWSサービス】

VPC、IAM、Direct Connect

もうすぐ入社丸3年になります

旅行

お稽古

時事

ﾌｧｯｼｮﾝ

飲食

「選択・意思決定・行動」を支援する

情報サービスの提供しています

進学

就職

結婚

転職

住宅購入

車購入

出産/育児

Life Event ライフイベント

Life Style ライフスタイル

ショッピング

★リクルートグループのサービス

リクルートキャリア

リクルートジョブズ

リクルートスタッフィング

リクルート住まいカンパニー

リクルートライフスタイル

リクルートマーケティングパートナーズ

スタッフサービス・ホールディングス

リクルートアドミニストレーション

リクルートコミュニケーションズ

事業会社

機能会社 インフラ部門

大規模プロジェクト推進部門

UI設計/SEO部門

ビッグデータ機能部門

テクノロジーR&D部門

事業・社内IT推進部門

リクルート ホールディングス

クラウドチーム

主な 提供先

★リクルートテクノロジーズについて

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

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

基本構成は1サイト＝1VPC ≒ 1アカウント

・・・

Elastic Load

Balancing

EC2 Instance

Web App

Server

VPC Subnet VPC Subnet

×

70以上….

この状態で 全サイトに共通機能を提供しようとすると、

NW構成が複雑になってしまいました…

どんな共通機能？

ログ収集サーバで各サーバの

システムログやアクセスログを集めて S3に保管しています

ログ収集サーバ

利用者環境

共通基盤環境

S3

td-agent

ログ管理スクリプト

VPC間をVPNでつないでログを送っています

VPC Subnet

Elastic Load

Balancing

Web App

Server

VPC Subnet

td-agent

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

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での監視（死活、ポート、プロセス等）

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

Cacti

CactiもVPNでつないでいます

VPC Subnet

GUI画面はここで提供

Elastic Load

Balancing

Web App

Server

VPC Subnet

snmp-agent

共通基盤環境

利用者環境

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

管理APIサーバ

VPC Subnet

ログ収集サーバ

Zabbixサーバ

Availability Zone

S3

Cactiサーバ

Web App

Server

これがVPCベストプラクティス...!!

Region

TOKYO

California

開発Zabbixサーバ

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

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

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

サービス系インフラDC (オンプレ）

社内業務系インフラDC (オンプレ）

別DC

AWSはサービス系インフラDCとはつなげています

管理APIサーバ

VPC Subnet

VPC Subnet

ログ収集サーバ

Cactiサーバ

Availability Zone

サービス系インフラDC (オンプレ）

認証機能をオンプレ側で共通利用

業務で利用するシステムの場合、 業務ネットワークとAWSもつなぐ必要がで

てきたりします

AWSを社内業務系のインフラとも一つVPCをつなげてみました

VPC Subnet

Availability Zone

社内業務系インフラ (オンプレ）

社内業務で利用+インターネット直接接続はなし

Proxy メールGW NFS VPN

Connection

しかし、サービス系インフラと 社内業務系インフラはIP体系が違うので、

共通提供機能を使おうとすると、

・・・NATするしかないので、こうなりました

社内業務系インフラ (オンプレ）

サービス系インフラDC (オンプレ）

管理APIサーバ

VPC Subnet

ログ収集サーバ

Zabbixサーバ

Availability Zone

VPN

Connection

VPC Subnet

Availability Zone

Proxy メールGW NFS

VPN

Connection

NATでVPC間通信

サービス系インフラのIP体系

業務系インフラのIP体系

ここまでの全体図

サービス系インフラDC (オンプレ）

管理APIサーバ

VPC Subnet

ログ収集サーバ

Zabbixサーバ

Availability Zone

VPN

Connection

Availability Zone

Proxy メールGW NFS

VPN

Connection

社内業務系インフラ

S3

Cactiサーバ

Web App

Server

VPN

Connection

これがVPCベストプラクティス...!!!

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

なぜベストな気がしないのか

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

もっとベストにするには

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

お願いVPC！お願いIAM！

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

いませんが多少変えられるように）なったらと思います...

お願いVPC！

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

これからの野望

AWS中心にいろいろなインフラと連携する ＝究極ハイブリッド！=複数VPC必須！！

=VPC（+付随する権限とかGW）の機能拡張

に期待！！！

ありがとうございました

リクルートテクノロジーズ