グリーの様々なサービスを支えるクラウド運用およびデータ分析基盤

Size: px

Start display at page:

Download "グリーの様々なサービスを支えるクラウド運用およびデータ分析基盤"

ひできあんさい
5 years ago
Views:

1 グリーの様々なサービスをえるクラウド運およびデータ分析基盤

2 紹介グリー株式会社インフラストラクチャ部堀真司やっていること主にクラウド環境の設計開発運ゲームそのものの開発協は少ないコンソールの操作よりプログラムを書くが多いやっていたことコンシューマーゲームオンラインゲームアーケードゲーム弊社いわゆるゲーム業界の横断部署や基盤技術を扱うチームがほとんど

3 AWS をとりまく環境スタートアップ系や規模サイトなどもクラウド環境が多めゲーム以外 SNS Platform ゲームフィーチャーホン時代からの SNS 中とした GREE はオンプレミスが多め負荷や気が安定しないゲームはクラウド環境多め

4 AWS 環境のゲームと規模感消滅都市２リリースからそろそろ三年 AWS オンプレ AWS という歴史ありホーム画とバトルをき来いわゆる JRPG でソシャゲとちょっと違うクローズ済みも含めて結構多いららマジ武器よさらばアナザーエデンゲームアカウント数インスタンス数利者数多数

5 アカウントの区切りゲーム本番環境 Amazon EC2 や Amazon RDS が多めゲーム開発環境各ゲームや部署毎に由に使ってよい規模 Amazon CloudFront と Amazon S3 だけの静的サイト WordPress + Amazon RDS が組だけあるような共通分析基盤やセキュリティ上の都合など関連会社協会社検証環境全部で 200 弱

6 アカウント依存関係アカウント / リージョン固有リソースは VPC を分けるだけでは不分リスクが少なくスピード重視の環境は各々の裁量で運してもらう IAM の権限をなるべく様に設定するためアカウント毎区切るゲーム本番環境ゲーム本番環境開発環境規模関連会社インフラチームが呼ばれたときにだけ相談に乗る共通系

7 共通系でやっていることゲーム本番環境共通系アカウントには他プロダクト他部署の情報も含まれているため的にしかアクセスできない情報の流れ的には Push/Pull どちらもあるモニタリングアナリティクス運ツールセキュリティ

8 途ごとにアカウントを分けているのでアカウントの数がとても多くなってしまっている

9 アカウント開設初期順がいブラウザでるとこのぐらいい印刷すると 38 ページにも及ぶ IAM 設定 AWS CloudTrail 設定 AWS Lambda 設定 AWS Config 設定その他情報の記録 GitHub Spreadsheet

10 Amazon EC2 など VPC を使う環境はさらに続く要件にもよるけどだいたいどのような案件でも同じようなものが必要になってくる Network 設定 Amazon VPC Subnet SecurityGroup Route, Gateway ツールのセットアップ IAM 設定 AWS Lambda 等など AMI 構築環境セットアップ Cookbook Jenkins DNS 関連 Amazon Route53 Bind モニタリング対応セキュリティ対応

11 とにかく順がいいと間違えやすいなるべくツール化

12 ツール化も安泰ではないシェルスクリプト ruby 2.3 nodejs 4.3 そもそもツール利までの障壁がい Windows 利者が結構ツライエラーが出たりすると問い合わせがすぐに来るテストが書きにくい検証アカウントでテストしてるが費は発する実際にリソースを成するので時間もかかるモック作るにも実装がめんどくさい CLI や SDK 叩くにしてもそもそも実装がくなりがち Amazon EC2 Instance を良い感じに複製するツール nodejs で 450 IP アドレスの棚卸ツール.sh で 50 々なリソース覧を表するツール ruby で 1100 年 30 個ぐらいのペースでツールが増える ( 概算 ) 技術的負債化が激しい

13 万事オッケーではないそこで AWS CloudFormation

14 AWS CloudFormation おさらいデータ定義で各種サービスリソースの構築ができる JSON と YAML が対応 Update したときは部分的に更新される冪等性がそこそこある組み込み関数がいくつかあり関数型語っぽく書くこともできる字列操作条件による選択パラメータの取得依存関係の順序量のアカウントがあってもテンプレートを読み込ませるだけ量複数に向いている気がする

15 主な途 Amazon VPC や SecurityGroup などの初期構築ほかの VPC と被らないように名前や Cidr アドレスをパラメータにしている Amazon RDS や Amazon ElastiCache などのインスタンス構築パラメータグループを分けいつも同じようなパラメータはここで設定 default でも分動くけどゲームに若チューニングノード数や途毎にテンプレートも分けてある AWS Lambda 関連 AWS Lambda 単体で運はほぼ無い IAM Role 作成 Amazon CloudWatch Events 設定 Amazon API Gateway や Amazon S3 Amazon SNS など関連リソースも緒に作成ダミーの Function だけ設定しプログラムのアップロードだけ別途う

16 組み込み関数だけでは物りないので nodejs で js を eval して JSON.Stringify している左辺のダブルクォートが不要要素の最後のカンマはあっても無くても良い普通に JavaScript で式が書ける複数のリソースを作るときは Object を返す関数を作ったりパラメータを map で選択したりループを展開したりコメントが書けたり AWS API でテンプレート外のパラメータを収集むしろこれができないとつらいテンプレートのデプロイツールでバリデーションもある AWS Console から Create/Update はしない罠対策 Tags : [ { Key : Name", Value : "master" }, { Key : Role", Value : { "Fn::Join": ["-",{ Ref : "Prefix" }, { Ref : Suffix" } } ], Tags: { Name: "master", Role : prefix suffix, }, // comment

17 きみの罠? Your trap? AWS 三難解サービスのうちのつ AWS CloudFormation

18 リソース名を変えると再成されてしまう Resources オブジェクトのフィールド名は変えないほうがよい Resources 単位で作成削除更新されるかけ上は Resources 名を変えただけでも別物として扱われる IAM Role でやった場合 Instance Profile が外れる今は付け替えできるけど昔は Instance 作り直すしかなかった Amazon RDS でやった場合 \(^o^)/ ほかにも再成されるケースがある Web Console で変更できないものを変更しようとすると危険な可能性あり AWS::RDS::DBInstance タイプの DBInstanceIdentifier \(^o^)/ 変えられなさそうなところは変えない Web Console なら Replacement の項をよく確認

19 Delete はめられない普通にオペミスなどで削除してしまうケース依存リソースがあっても削除可能な場合は完全に消える IAM Role SecurityGroup 依存リソースがブロックになる場合は部分的に消える Amazon S3 Bucket Object がつでもあると削除できない Amazon VPC や Subnet など削除できない消せないものを残して Delete が時停する DeletionPolicy を設定すべき Retain にすると Delete しても削除されず無視される Snapshot にすると状態が残せるリソースでは最終スナップショットを取得してからインスタンスを削除する AWS::EC2::Volume, AWS::ElastiCache::CacheCluster, AWS::ElastiCache::ReplicationGroup, AWS::RDS::DBInstance, AWS::RDS::DBCluster, and AWS::Redshift::Cluster とはいえ残ったリソースをマニュアルで削除しないといけないのでオペミス対策にはならない

20 同期で処理されるのでスクリプトに組み込みにくいシェルスクリプト Rakefile テンプレートの Create 戻って引き続き処理など (2016 年 3 ごろの更新で wait パラメータが対応 ) 独のデプロイツールを準備.js.json の変換だけではない diff の表と dryrun COMPLETE 状態になるまでポーリング Parameter の設定簡略化 Output の標準出化罠というよりは CLI をよく使う企業化によるもの作業記録が取りやすいので

21 部リソースはランダムな字列が与えられる IAM Role 名 Suffix に 12U3DBD4GB5D みたいな字列がくっつくテンプレート内での Ref 関数には問題なし乱数が含まれると他のツールで設定しにくかったり単純に通しが悪い独ツールで対応 Subiam を使い AWS の IAM 管理をコードベースでおこなう省略可能な名前を省略したとき Redis ノード名など API Gateway の部リソース Amazon CloudFormation 関係なくランダムかも

22 ほかにも部プロパティーは対応しておらず Web Console や CLI に劣るバリデーションの動作が違うこれは Web Console と CLI でも違うことがある Amazon API Gateway / AWS Lambda 周辺で記述量が多くなりがちそれでもツール化や順書よりは短いし安全

23 使わないよりは圧倒的に便利複数アカウントで効果絶かゆいところはで対応 AWS CloudFormation

24 データ分析基盤

25 グリーの分析基盤分析対象によってきく分けると 2 種類 GREE Platform く続いていてログに関する変更は多くない MySQL オンプレ Hadoop ゲーム新規事業新規リリースやイベントなど頻繁に変更がるオンプレ Hadoop AWS Treasure Data 今話す内容

26 ゲームや新規事業の分析体制データエンジニアリングチームは分析基盤を開発運各プロダクトの担当者は分析基盤使してプロダクトの分析を実分析のプロのアナリストチームは各プロダクトのサポートプロダクト分析のサポート分析基盤の提供アナリストチームデータエンジニアリングチーム

27 グリーで必要とされる分析基盤の機能社内共通のKPIの集計プロダクト独にダッシュボードを作成アドホックなクエリの実分析途やサポートツールのバックエンド途利者の権限管理低コストな各プロダクトへの導やサポート多数のプロダクトがあるためつつに厚いサポートができない

28 AWS に分析基盤を作成した理由全社的にクラウドへ移する流れクラウドを利したがサーバー増減が容易マネージドサービスを使することでメンテナンスコストを軽減可能 AWS 上に分析基盤を構築し新規プロダクト順次使開始

29 分析基盤の構成プロダクト A プロダクト B プロダクト C Amazon Kinesis Amazon S3 API Server BI Tool プロダクト D Kinesis Consumer Amazon EMR KPI Metric

30 ログの送受信部分についてプロダクト A プロダクト B プロダクト C Amazon Kinesis Amazon S3 API Server BI Tool プロダクト D Kinesis Consumer Amazon EMR KPI Metric

31 Amazon Kinesis Streams 規模ストリーミングデータのためのマネージドなデータストレージプロデューサーとコンシューマープロデューサー : Amazon Kinesis Streamsにデータを送信コンシューマー : Amazon Kinesis Streamsのデータを処理シャードストリーム内のグループシャードごとに読み書きにキャパシティがあり増やすことでスケールする Kinesis Producer Library(KPL) 書き込む際レコードを集約することで効率よくデータを書き込めるライブラリ

32 ログの送受信について 1 のログ量は 500GB ~ 800GB 程度プロデューサー fluentdからkplを使して送信 Amazon DynamoDBの更新イベントをDynamoDB Streamを経由して AWS Lambdaから送信コンシューマー Kinesis Consumer Library(KCL) でログを取り出して Amazon S3 に保存プロダクト A Amazon Kinesis Consumer Amazon S3

33 ログの処理部分についてプロダクト A プロダクト B プロダクト C Amazon Kinesis Amazon S3 API Server BI Tool プロダクト D Kinesis Consumer Amazon EMR KPI Metric

34 Amazon EMR Hadoop などの実が容易なクラスタプラットフォーム複数のアプリケーションをクラスタで実できる Hadoop, Hive, Spark etc.. クラスタはEC2インスタンスで構成されていてクラスタ起動時に選択したアプリケーション (Apache Sparkなど ) があらかじめセットアップされた状態で使できるクラスタ構築時に任意の処理を追加可能 (Bootstrap Action) 独に作成したHiveのUDFを追加する等

35 ログ処理部分 SQLエンジンであるHiveとPrestoを使 Hive, Prestoそれぞれ別のAmazon EMRクラスタで起動 APIサーバーからAmazon EMR 上のHiveとPrestoにクエリを実ストレージにAmazon S3を使しているので EMRクラスタれ換えが容易 Amazon S3 Amazon EMR API Server

36 ユーザーインタフェースプロダクト A プロダクト B プロダクト C Amazon Kinesis Amazon S3 API Server BI Tool プロダクト D Kinesis Consumer Amazon EMR KPI Metric

37 API サーバー実するクエリは全て API サーバーを経由して実 Web APIを公開していてクエリの実やクエリの結果を取得可能クエリの実結果は全てAmazon S3に保存権限チェック WEB APIは社内からなら由に使可能社内ツールや Bot などが使クエリを実する Amazon EMR クラスターの管理

38 BI ツール Web UIでクエリが実できるグラフを簡単に作成できる社内ドキュメント上で柔軟にレポートやダッシュボードが作成可能グラフデータはAmazon DynamoDBに保存登録したクエリを定期実することが可能ワークフローには digdag を使

39 分析基盤運での AWS の活

40 次セキュリティ & アクセス制御変更に強いインフラ運効率化のためのツールの活

41 セキュリティ & アクセス制御 (1/2) AWS アカウントを跨いだアクセス制御例 : Kinesis Streams へデータを送信するプロダクトを管理しておきたいプロダクトと分析基盤では AWS アカウントが異なるアクセストークン漏洩などのリスクを抑えたいプロダクトが増えると漏洩のリスクが増える楽に管理したいアクセス権の発 / 停利状況の把握など

セキュリティ & アクセス制御 (2/2) Cross Account の IAM Assume Role を使

トークンの発が不要利状況は AWS Identity and Access Management

1. AssumeRole で時的権限を取得 IAM Role (Kinesis への Write 権限 )

42 セキュリティ & アクセス制御 (2/2) Cross Account の IAM Assume Role を使プロダクトの AWS アカウントにデータ分析基盤の IAM Role を Assume Role する権限を付与トークンの発が不要利状況は AWS Identity and Access Management のコンソールで確認可能利停も再開も簡単データ分析基盤の AWS アカウントプロダクトの AWS アカウント 1. AssumeRole で時的権限を取得 IAM Role (Kinesis への Write 権限 ) Amazon EC2 Amazon Kinesis Streams 2. Kinesis::PutRecords でログを送信 AWS Lambda

43 変更に強いインフラデータの保存場所とデータ処理をする場所の分離データ処理部を容易にスケールさせられる新たなデータ処理部を簡単に導でき障害対応も容易 EMR クラスタはステートレス化して使クラスタ内に永続的にデータを保存しない Hive/Presto のオートスケールが容易ログ量の増や分析基盤の利状況に合わせてパフォーマンスを柔軟に変更可能 Hive/Presto のバージョンアップも容易導前の検証を分にうことが簡単 Hive のバージョンアップ (Hive 1.x 系から Hive 2.x 系へ ) に伴うトラブルを事前に回避できた旧 Hive/Presto Amazon EMR API サーバ BI ツールユーザ旧 Hive/Presto Amazon EMR 破棄 API サーバ BI ツールユーザ Amazon S3 検証新 Hive/Presto Amazon EMR Amazon EC2 Amazon S3 新 Hive/Presto Amazon EMR 切り替え Amazon EC2

44 各種ツールの活による運の効率化省化 (1/4) データ分析基盤の運運専任のメンバーは存在せず開発者が本番環境の構築運もっている AWS の各種 API や周辺ツールを利した効率的な運インフラの構築変更をプログラマブルにうことが可能事細かな運順書が不要量の順を正確に素早くうことが可能少数でも効率的に運を回せる

45 各種ツールの活による運の効率化省化 (2/4) AWS CloudFormation 堀の発表参照 ( データ分析基盤では )AWS アカウントの初期設定にのみ使 Terraform マルチクラウド対応のインフラストラクチャ管理ツールシンプルで読みやすいフォーマット ( 右参照 ) リソース間の連携を記述しやすい運中に頻繁に変更されるものではないリソースの管理に使 Security Group, IAM Role/User, Amazon S3 の BucketPolicy, Lambda Function, Elastic Load Balancing Amazon Route53, Amazon CloudWatch IAM Policy の記述例 (Terraform) resource aws_iam_policy write_s3 { policy = <<EOF { "Statement" : [{ Resource : ${aws_s3_bucket.foo.arn}, "Action" : "s3:put*", "Effect" : "Allow"} ]} EOF } Security Group の記述例 (Terraform) など resource aws_security_grpup allow_office { vpc_id = xxxxxxxx ingress { from_port = 443 to_port = 443 cidr_blocks = [ xxx.xxx.xxx.xxx/yy ] } }

46 各種ツールの活による運の効率化省化 (3/4) Chef サーバ構築と構成管理のためのフレームワーク ( データ分析基盤では )AMI の作成に使 AWS CodeDeploy プラットフォームや語に依存のデプロイ管理ツール Web Console や API で操作可能なのでデプロイサーバが不要アプリケーション依存の処理はスクリプトでカスタマイズ可能 Kinesis Consumer, API サーバ BI ツールのデプロイに使ダウンタイム無しでデプロイデータ分析基盤でのデプロイの様 2. Download code ビルドサーバ Amazon EC2 1. Upload code Amazon S3 デプロイ対象サーバ Amazon EC2 3. Detach instance from load balancer 4. Stop application and deploy code to itself 5. Start application and attach to load balancer

47 各種ツールの活による運の効率化省化 (4/4) AWS Lambda 定期的な処理の実に使専のサーバを意しなくて済む分析基盤での例 Amazon DynamoDB の Capacity 調整集計 batch が動く早朝に Write の Capacity を上げる中および深夜は下げる中は Read の Capacity を上げる早朝および深夜は下げる EMR クラスタや API サーバの E2E 監視実際にクエリを投げてみる異常を検知したらチームメンバーへアラートを通知 Lambda Function を追加するだけで監視項が増やせる検知ロジックをプログラムで書けるので実現できる監視内容の幅が広い Hive の Partition 追加 1 1 回実

48 データ分析基盤まとめ AWS の様々なサービスを活することで柔軟なデータ分析基盤を構築することができた Amazon Kinesis Streams Amazon S3 Amazon EMR 必要に応じてカスタマイズすることで社内のニーズにあったシステムを作ることができた API サーバ BI ツール運においても AWS のサービスや OSS ツールを活しリーズナブルかつ効率的な運をまわすことができた Terraform Chef AWS Lambda AWS CodeDeploy など

AWS Deck Template

AWS Deck Template AWS OpsWorks のご紹介 Amazon Data Services Japan 2013/06/25 Agenda AWS OpsWorks とは OpsWorks の特長 OpsWorks 利用の流れ OpsWorks のメリット Chef とは OpsWorks のライフサイクルイベントどのようなアプリケーションが OpsWorks に向いているのか? OpsWorks の機能詳細