DMM における会員基盤プラットフォームへのAWS導入から活用事例の紹介

Size: px

Start display at page:

Download "DMM における会員基盤プラットフォームへのAWS導入から活用事例の紹介"

とよみすずがみね
5 years ago
Views:

1 DMM における会員基盤プラットフォームへの AWS 導入から活用事例の紹介株式会社 DMM.com ラボ岩崎磨 / 飯田涼太 / 西村政輝 AWS Summit Tokyo

2 法務情報 DMM は第三者の製品サービスについて特定の製造者やサービス提供者につき製品やサービスを評価するものではありません当社事例はあくまで当社事案であり各社のシステムサービス要件等によって機能パフォーマンスその他の面で該当しない場合があります本プレゼンテーションは当社構築した AWS システムに関する技術者の現時点での感想に基づいています 2

3 発表者紹介 IT戦略本部本部長 I Infrastructure. システム本部チームリーダー I Kanazawa. システム本部リードエンジニア I Scala. 3

4 アジェンダはじめに DMM のクラウドへの取り組み状況事例前半会員基盤フロントエンド改修に合わせて AWS 移行した話事例後半内製基盤アプリケーションの AWS 移行におけるマネージドサービス活用例 4

5 DMM のサービス紹介 5

6 DMM のクラウド利用状況 6

7 DMM でのクラウド利用状況推移 EC2 利用時間毎年前年度比率 2 倍強で利用リソース量増加ゲームでの活用から基盤への展開フェーズへ 2017 年データは 5 月時点での予測値 2014 年 2015 年 2016 年 2017 年 7

8 DMM クラウド推進の取り組み 8

9 大切にしていることスピード感何かあっても作ってからごめんなさいするスタイル (DS 方式 ) 標準化ではなくリファレンス化ルール ( 標準化 ) の押し付けでは活用は広がらないエンジニアが作った機能を横展開して皆の効率をあげていく軸 9

10 勉強会はたくさん開催エンジニアはみんな勉強会大好き新社屋セミナースペースを活用してAWS勉強会を連日開催 10

11 開発者向け AWS 自由利用環境の提供 DMM のエンジニアデザイナーは AWS 環境を私的利用でも自由に利用できるようにしました名付けて AWS 実弾演習場 DMMの開発者 1 人ひとりにアカウントを発行しAWSサービスが好きなように試せる環境を提供コストについては使いすぎ抑止のためにBillingAlertを設定新機能のAWS Organizationsでアカウント作成 BillingAlert 設定権限剥奪については集中的に運用 11

12 会員基盤フロントエンド改修に合わせて AWS 移行した話事例紹介前半 DMM 会員機能の一部の AWS 移行について AWS Summit Tokyo

13 事例の概要背景としてオンプレ上で稼働するモノリシックなサービス基盤が存在急激な事業拡大による運用コスト肥大化が課題もっと事業をリードできるスピード感を求めてマイクロサービス化を進めていく中で AWS を利用したら解決が捗りました! 13

14 アジェンダ当時基盤の課題点私たちの解決事例まとめ 14

15 当時の基盤の課題点 15

16 当時の基盤の課題点基盤としてまだ改善の余地が見込める 1. もっと運用をツール化できる 2. もっと検証精度を上げられる 3. 検証時間も短縮できる 16

17 課題点の具体例 1 インシデントやイベント対応など運用がツール化できておらず属人化しがち対応が後手に回り復旧時間が長期化障害担当者連絡担当者対応復旧 17

18 課題点の具体例 2 サーバの維持管理を含めた費用対効果の観点から検証環境と本番環境の構成が一部異なり検証環境では再現しない場合がある開発環境 OK 検証環境 OK ユーザ環境 NG 18

19 課題点の具体例3 モノリシックかつ複雑な基盤となっており変更は小さくても影響が小さいとは限らない常にじっくり時間をかける保守的な対応 Web Server 19

20 私たちの解決事例 20

21 課題点1: 復旧時間の短縮に向けて Availability Zone Availability Zone virtual private cloud 21

22 課題点1: 復旧時間の短縮に向けて Multi-AZの Auto Scaling Groupを設定 Multi-AZでの Clustering Availability Zone Availability Zone virtual private cloud 22

23 課題点 1: 復旧時間の短縮に向けて基本的に人の手を介さずに設定に従った自動復旧を設定することで Multi-AZ 高可用性と AWS のマネージドサービスにより復旧までを時短化障害担当者連絡担当者対応復旧 23

24 課題点 2: リリース前の検証精度向上に向けて必要な時だけ全く同じ構成の環境を用意関係者 ONLY ユーザ用検証用 24

25 課題点2: リリース前の検証精度向上に向けて検証が済んだらアクセスもリソースも解放ユーザアクセスを解放リソースを解放ユーザ用検証用 25

26 課題点 2: リリース前の検証精度向上に向けて 26

27 課題点2: リリース前の検証精度向上に向けて構成をstackとしてテンプレ化し AWS CloudFormationで環境を量産 Ansible + Packerでベースとなる Amazon Machine Imageを用途ごとに作成 27

28 課題点 2: リリース前の検証精度向上に向けてクラウドのオンデマンドなリソースに AWS CloudFormation をかけ合わせることでサーバを遊ばせずにいつも同じ状態で検証可無駄もなく効率的に事前検証精度を向上開発環境 OK 検証環境 OK ユーザ環境 OK 28

29 課題点 3: 検証時間の短縮に向けてマイクロサービスとして分離し影響範囲を明確化 Web Server Web Server Web Server Web Server LB 29

30 課題点3: 検証時間の短縮に向けてマネージドサービスを利用した変更管理により漏れなく対応しつつ新規に生成した環境でスピーディな検証が可能に 30

31 課題点 3: 検証時間の短縮に向けて AWS を利用することでマイクロサービスとして影響範囲を明確にするだけでなくその時々に応じた最適なリソースをスピーディかつ正確に構成して検証可能に対応周知じっくり検証日時調整実施 31

32 まとめ 32

33 まとめマネージドサービスの活用 Multi-AZ の高可用性で障害を抑制障害時の自動復旧で時短化潤沢なリソースと CloudFormation の利用同一環境を無駄なく生成破棄検証精度を向上しつつ時間も短縮 33

34 内製基盤アプリケーションの AWS 移植におけるマネージドサービス活用例事例紹介後半 DMM の高ワークロードを支える API Gateway / OAuth2 認可基盤 AWS Summit Tokyo

35 アジェンダプロジェクト概要構成図 AWS 移行で得られたもの AWS 移行で注意したところスケーリングと性能見積もりサービスディスカバリ 35

36 プロジェクト概要構成図 36

37 プロジェクト概要オンプレミスで製造構築した内製 DMM API GatewayをAWSへ移行するプロジェクト最重要なのは耐障害性 DMM.comのプラットフォーム基盤の窓口となるシステム障害発生時の影響範囲が大きい APIの窓口としての安定性と低いレイテンシも必要オンプレミス側との通信にAWS Direct Connectも導入する 37

38 オンプレ時の構成図 / co.jp 他サブドメインなど (数千リクエスト毎秒) 今回のAWS移行対象内製 DMM API Gateway / OAuth2 認可基盤 (Akka Streams and HTTP製) Backend API servers LB (L4) モバイル端末提携先システム etc. LB (L4) 38

Parameter Store AWS Direct Connect モバイル端末

39 AWS移行後の構成図 nginx ALB MySQL RDS Aurora HashiCorp Valut EC2 Systems Manager パラメータストア ECSクラスタ ap-northeast-1a ap-northeast-1c EC2 Systems Mamager Parameter Store AWS Direct Connect モバイル端末提携先システム etc.. DMM.com データセンター Redis Sentinel ElastiCache (Redis Cluster) 39

40 ECSタスクと関連するコンポーネント Application Load Balancer APIコール(HTTPS) Amazon ECS アプリケーション本体のコンテナ HTTP/HTTPSはALBと連携 Agent類はSidecarパターンで用意 Datadog Agent アプリケーション監視メトリクス収集 APIコール(HTTP) fluentd with fluentd-kinesis-plugin Kinesis Firehose S3へログ収集メトリクス収集ログ収集アプリケーションタスク構成 Amazon Kinesis Firehose Amazon S3 40

41 AWS 移行で得られたもの 41

42 AWS 移行で得られたもの 1. 堅牢なインフラ環境の入手複数データセンター級の冗長性 (Multi-AZ) インスタンスプロセス障害時のオートヒーリング 2. ミドルウェア運用からの解放手段 : フルマネージドサービスの活用 ALB+ACM ECS RDS ElastiCache Kinesis Firehose EC2 Systems Manager パラメータストア採用例少ないと思うので次で紹介します! ( 他はありふれてるサービスのため省略 ) 42

43 EC2パラメータストアでできたことアプリケーション用のシークレット値の取得格納管理コンソールや AWS CLI AWS SDKを用いての操作 AWS KMSと連携しシークレット値を暗号化できたここ設定のイメージ例 43

44 EC2 パラメータストアで嬉しかったことシークレット値管理のミドルウェア運用等が省力化できた! 省力化対象 before ( 当社オンプレミス ) after (AWS) ミドルウェア運用 HashiCorp Vault (HA 構成 ) HashiCorp Consul ( クラスタ構成 ) nginx SSL 証明書管理必要不要 ( フルマネージド ) ACL 設計 HashiCorp Vault 固有の ACL AWS IAM に統合 44

45 AWS 移行で注意したところ 45

46 クラウド環境利用における注意点 1. 動的なスケーリングを前提とした Elastic な構成 AWS 移行後はインスタンス利用料が従量課金節約のためのスケーリングを行うことにした 2. 動的なネットワーク割当への対応 ( 例 ) アプリの設定変更をオートスケール対象全台にプッシュしたい AWS のサービスディスカバリ機能の活用で対応内部 DNS AWS CLI/SDK 46

47 ElastiCacheのレプリケーション遅延対策懸念 Redis (Master-Slave構成) のレプリケーション遅延局面 DMM API Gatewayへの連続リクエスト例: (Write) 認可要求 (Read) API利用時の認可判定対策 ElastiCache Redis Clusterを採用した上で Redis Clusterへの参照更新をプライマリノードのみに限定実質的なMulti-Master構成として活用メリットレプリケーション遅延の考慮が不要負荷対策 Redis Clusterのシャーディングで分散 47

48 スケーリングと性能見積もり 48

49 出典 DMM 2017 オートスケーリング戦略 DMMのサービスの特性としてオートスケールはスケジュールベースを基本として問題ない主要商材がエンターテイメントということもありピークタイムが夜間で不変であるため x軸単位時分(十の位) y軸単位秒間リクエスト回数赤4時間分と黄8時間分はオンデマンドインスタンスでスケールするオフピークの負荷はリザーブドインスタンス購入で節約 49

50 オートスケール設定で注意したことスケールアウト時の注意点主としてスケジュールベース副として負荷ベースを採用懸念負荷ベースではインスタンス起動やウォームアップが後追いイベント等のスケーリングだけ個別対応スケールイン時の注意点 ECSはドレイニング後のEC2インスタンスを自動でターミネートしてくれない現状( 現在) Lambda等で仕組みの構築が必要補足オートスケールインはDMMの場合早朝時間帯社員就寝中.zzZ 50

51 ベンチマーク概要観点リクエスト数ごとのレスポンスタイムはどの程度かインスタンスのスケーリングに応じてキャパシティもスケールするか条件下記インスタンスでの秒間 1 10,000 リクエスト時のレスポンスタイムコンポーネントインスタンスサイズ台数 ECS RDS (Aurora MySQL) ElastiCache (Redis Cluster 3 シャード ) c4.xlarge (4vCPU/8GB) db.r3.xlarge (4vCPU/30.5GB) cache.r3.large (2vCPU/13.5GB) 4,8,12 台でそれぞれ確認 4 台 (M1 RR3) 6 台 (M3 RR3) 51

52 ベンチマーク構成図 DMM API Gatewayを中心に負荷試験クライアントとAPIスタブを用意 APIスタブ (ping-pong) DMM API Gateway (OAuth2認可検証ルーティング) ap-northeast-1a HTTPS HTTP 負荷試験クライアント HTTP HTTP TLS終端処理 ap-northeast-1c 52

53 ベンチマーク結果(ECS 4台) (ms) 毎秒4,500リクエストが安定限界だったがオフピークはこれで十分そう見えにくいですが大体16ミリ秒くらいですタイムアウト10秒 53

54 ベンチマーク結果(ECS 8台) (ms) 毎秒6,500リクエストまで良好な成績毎秒1万リクエストにも対応参考 ECS 4台 54

55 ベンチマーク結果(ECS 12台) (ms) 毎秒1万リクエストにも余裕の対応明らかにオーバースペック参考 ECS 4台参考 ECS 8台 55

56 ベンチマーク結果(ECS 12台 percenitile値) AZ間の通信が頻繁に発生した場合でも19ミリ秒程度のレスポンスタイム外れ値を除外し 95パーセンタイル値まで掲載 56

57 サービスディスカバリ 57

58 LambdaベースでECSのディスカバリを実現 ③ 解決策の一つとして ECS上の配置情報をAWS SDKで取得し DMM API GatewayのIPとportを管理サイトへ通知するLambdaを作成 Lambdaの実行トリガーには ECSイベントストリームが利用できた ① ユースケースとして APIルーティング追加や OAuthスコープ追加など管理サイトからECS上の DMM API Gateway全台に更新をBroadcastしたい API Gateway 管理者 ② しかし ECS上の DMM API Gatewayはオートスケールする IPアドレスとportが動的に変わっていく ap-northeast-1a ap-northeast-1c 管理サイト (新規作成) 58

59 最後に 59

60 まとめ AWS 環境への移行で嬉しかったことマネージドで高可用なシステムが従来より簡単に構築できた! 高ワークロードなシステムの構築も問題なかった! AWS 環境の使いこなしで気を付けたことインスタンスの利用料はオートスケールの活用で節約サービスディスカバリは SDK 等の活用で利用者側が作成 60

ご清聴ありがとうございました本日のプレゼンテーションはDMMで構築したAWSシステムに関する技術者の現時点(2017.6.

61 ご清聴ありがとうございました本日のプレゼンテーションはDMMで構築したAWSシステムに関する技術者の現時点( )での感想に基づいています DMMは第三者の製品サービスについて特定の製造者やサービス提供者につき製品やサービスを評価するものではありません DMMは第三者の製品サービスについて何らかの保証を提供するものではありません

10年オンプレで運用したmixiをAWSに移行した10の理由

10年オンプレで運用したmixiをAWSに移行した10の理由 10 年オンプレで運用した mixi を AWS に移行した 10 の理由 AWS Summit Tokyo 2016 株式会社ミクシィオレンジスタジオ mixi システム部北村聖児自己紹介 2 名前北村聖児所属株式会社ミクシィオレンジスタジオ mixiシステム部担当サービス SNS mixi 今日話すこと 3 mixi を AWS に移行した話 mixi 2004 年 3 月 3 日にオフィシャルオープンした