JAWS DAYS 2015 参加レポート
JAWS DAYS 2015 に参加してきました。
昨年は都合が悪く行けなかったので、初めての参加。
会場の雰囲気はこんな感じ。
人気のセッションは立ち見だったので簡単になってしまったけど、以下、備忘のためメモアップします。
※後日資料が公開されたりするので随時更新しようと思います。
スマートニュースの世界進出を支えるログ解析基盤 on AWS
立ち見で途中から入ったのであまり全体の流れがメモできず。 気になったところ＋考察という形で。
インフラ構成について
・ストレージとアプリケーション層は分離すべき ・分離することでクラウドらしい設計になる
Azkaban
[特徴]
- ジョブ管理がしやすい
- ジョブをコードで定義
[デメリット]
- Azkabanのexecuterは一代しか持てない
http://sstd-bigdata.blogspot.jp/2014/09/azkaban.html
http://d.hatena.ne.jp/wyukawa/20150110/1420889758
初めて聞いた。ジョブ管理ツールはこれというものがなかったので、使ってみたい。
Presto
Facebookで開発されたクエリ実行エンジン。 今はTreasuredataなどでも使える。 自分も会社で使ってます。
クエリ実行エンジンでDBそのものではないから、 複数のデータソース（MySQL&Hiveなど）のjoinができる →以下のスライドが理解の助けになるはず。
Chatio
バックエンドが切り替えられるダッシュボード。 フロントエンドの作り込みが不要 見やすい、キレイなので毎日見る気が起きる。
BigQuery
すごい。あまり深いこと考えずにクエリ投げても返ってくるが、 データを扱う技術は追いかける必要があると思うので、使い分けが必要と思う
所感
成長とともにインフラもちゃんと成長してきているのが分かり、尊敬。 設計思想などは現場の実感が込められているのが伝わってきました。
まる見え、AWS!! ～CloudTrailとConfigからわかるAWSオペレーションのすべて～
CloudTrailはまだちゃんと使えていないので、ノウハウなど得られるといいなと思い。
Cloud trail
AWS APIの呼び出し履歴が取得出来るいわゆる監査ログ記録・管理のためのログ送信ツール。
AWSセキュリティ編～CloudTrailの活用～ – ナレコムAWSレシピ
Management Consoleの操作などNon API call のイベントも取れる JSON形式での出力でどうするか？というのは使い方次第。
「現在有効にしていない人は今すぐ有効化してください！」というほど大事なサービス。
使い道
- アラート検知
- 文字列検索
- 可視化
Cloud trail のログをcloud watch logs に連携 メトリックフィルタを作って特定インスタンスタイプが作られたらアラート飛ばすなど クラウドformationでメトリック作れるのが出来た。楽にできるはず。
CloudSearchに入れてログを検索したい！
例えばあらかじめ拾いたいメトリックスをフィルタにして、SNS,SQSを使って Elastic searchにいれてKibanaで見るなどの仕組み
Aws config
設定変更がどのインスタンスやセキュリティグループと紐付いてるかを一気に取れる 既にLog strageなどいくつかの製品と連携している 例えば古いAMIから上がっているインスタンスはどれか？などもわかる
所感
CloudTrailって監査ログってイメージだったのだけど、積極的に可視化するという思想はあまりなかったんだけど、やっぱりちゃんと検知・分析できる仕組みを構築しないと、と思いました。
www.slideshare.net
「OpsworksでDevOpsを感じよう」、「OpsWorkの仕組みと活用方法の紹介」
続けて聞いたのでこちらはまとめてメモ。
OpsWork
- 2013年2月よりローンチしたサービス
- プロビジョニング、設定管理、デプロイメント、監視及びアクセス制御など
- 複雑なアプリケーションライフサイクルのための管理ソリューション
OpsWorksで設定管理に関係するaws項目
EC2,VPC,ELB,EBS,RDS,IAM
スタック
OpsWorksのトップエンティティ、全体の設定を行うところ
スタック作成の準備
- リージョン
- VPC
- EC2 などなど
上記ができていれば、コンソールからポチポチ デフォルト設定をする （詳細作成の際に変更していくことは可能】
最初にNWを作って、OpenにしておかないとOpsWorksのエージェントが通信できない
レイヤー
OpsWorksには「レイヤー」が必要。なんすかそれ。。 (例) * HA Proxy * App Rails App Server, PHP AppServer * DB ** MySQL などなど
インスタンス、スケールタイプを指定
OpsWorksを使うと良くなるところ
EC2起動、ソフトウェアインストール、デプロイの自動化
Capistranoなどのツールを使えば自動化出来るが、AWSのマネージド機能ではできないので利用価値はある
OpsWorksで起動したインスタンス内部で起動するOpsWorksエージェントがChefレシピを実行可能
OpsWorksエージェントからOpsWorksエンドポイントに対してPolling
- OpsWorksによって発行された一連のコマンドを取得して、Chef solo（Chef Zero）でレシピを実行 ※Chef Serverと通信するわけではない。あくまで単体実行
- Chefのレシピやアプリケーションコードは指定したコードリポジトリから展開（Git等）
OpsWorksで実行可能なコマンド（2種類）
- スタックコマンド
スタック全体の構成を変更・管理するためのコマンド、MCから実行可能
- エージェントコマンド
基本はスタックコマンドを使う
- スタックコマンドを使って、リモートから任意のタイミングでインスタンスにコマンドを実行可能
→MCから指示するだけ
- レシピを自動実行させるために、ライフサイクルイベントを利用 （Setup,Configure,Deoloy,undeploy,shutdonw) ←Chefのビルトインレシピ
カスタムレシピをもちろん利用可能
どうやってライフサイクルイベントを利用するの？
→最初のインスタンスを起動すると、Setupが呼ばれる→Deployが走る→全てのレシピが成功したらConfigureイベントが呼ばれる
利用例
- 運用関連タスクの自動化の例
- セキュリティ脆弱性に対するソフトウェア・パッケージアップデートをChefレシピから自動で展開するなど （再起動とか、Perlパッケージとか、気にしなくて良い構成にしてないとダメよね。。）
www.slideshare.net
www.slideshare.net
- OpsWorkのハンズオン資料 www.slideshare.net
ランチ
参加費1000円は払ってるものの、タダ飯が食えるという太っ腹なおまけ付き。
ランチセッションもやってたけど、あまり見たいのがなかったのでゆっくり食べてました。
腹ごしらえして、さぁ午後のセッション。
MMO RPG on AWS
ソリューションアーキテクト今井さんのセッション！ いつもお世話になっております。
今回は韓国のSAユンジンさんとの共同セッション。 ユンジンさんが英語でプレゼンし、今井さんが日本語で訳すというチャレンジングなセッション。 カッコええ。
NexonoのMMORPG環境の運用事例の紹介をしてくれました。
MMORPGとは
- Massively Multiplayer Online Role Playing Game
- 非常に多数のユーザが同時接続し、インタラクションしながら進めていくゲーム
MMORPG on AWS needs - Massive message handling -
- 膨大な数のメッセージのハンドリング
非常に多くのユーザが同時に接続して、魔法を使うと他のユーザにダメージが出るなど、同時インタラクション要素が非常に多い(N - N)
- 1台→スケールさせるためにはどうするか？
オンプレだったら、TCP,UDPで独自プロトコルの上でマルチキャストを実現 ** が、AWSではマルチキャスト、ブロードキャストはサポートしてない。どうするか？
PubSub (Publish-subscribe) モデルを使う ** SNS,Elasticache,RabbitMQなどを使って実現
ZeroMQを使った C,C++実装、速い No brokerノードの仕組みなので、No SPOF
Game server load balancing
1つワールドを実現するには、サーバ毎にセッションを分ける等を行っていたが（どっかで昔聞いたような・・・） それをどうやって複数サーバで1セッションを実現するか。
1つのGameのMap上で離れた島（国？）間はあまりインタラクションが発生しない。別々のセッションにできる
- エリアの特性によって、ユーザの偏りがあるためロードバランス上課題となる
- Low densityエリアは1台のサーバで広くカバー
- High densityエリアは複数のサーバでカバー
- ダイナミックにサーバをAllocationさせる
- 複数のサーバでカバーしているところはいかにインタラクションさせるか？
- エリア内でユーザが大きくなってきてしまったら、Geo locationで分割
- 分けたサーバ間でデータをsync
Minimize data sync
データ同期を最小化するための仕組み
例：植物、動物、人（ユーザ）が登場人物 それぞれを別サーバに切り出し、マップ上の同じ場所で動きがある部分（オーバラップしたところ）だけ インタラクション（同期）する
Ghost abstraction
以下に低レイテンシで大量のI/Oを実現するか
- MMOの各ユーザの持つデータは様々
全てDBに格納する必要がある
基本は非同期I/O
- NoSQLを使う
- DynamoDB
- MongoDB
- CouchDB
RDBでなくNoSQLな要因？
- 今更だが、DBスケールアップで限界が来るとビジネスが頭打ちになる
スケールアウト可能なアーキテクチャ
多くのアイテムを如何に高速に検索して返すかというのが重要なポイント
- NoSQLと CloudSearch or ElasticSearch を用いる ** EC2-ElasticSearch-NoSQL
(この連携の仕方がよく分からん。。)
まとめ（抜粋）
- Ec2のエンハンスドネットワーキングはとても優秀
- NoSQLと検索の組み合わせ
- データ同期の平均所要時間を縮めるために非同期I/Oを利用する
- 分散環境においてゲームキャラクタ同士のインタラクションを実現するためにRPCを利用する
Q&A
- ブロードキャスト、マルチキャストをサポートする気があるか→今のところプランなし
- ちなみに使いたい人は？→会場では少数
そんな話題にフォーカスすること自体、自分にとっては少々驚きでした。
所感
ゲームの運用をここまで掘り下げて聞けたのは初めてだったのでとても興味深かった。 この業界は本当にテクニカルで難しそうだけど、面白そうだな、と思いました。
開発するように運用するインフラ （Kaizen Platform）
超人気セッションに。naoya氏の露出の影響が大きいためか、皆名前を知っているのだろう。
Kaizen Platformの事業
サイトのA/Bテストをするインフラを提供
- 管理画面
- Js配信
- jsの計測
→jsを埋め込んで、計測する
すべてインフラはAWSを利用 ELB,EC2,RDS,ElastiCache というシンプルな構成
色々とSaaSを使っているので、主にGitHubとCircleCIを使った開発・運用について紹介
Githubでの開発プロセス
- Work in progressでpullrequest（マスターbranchから開発branchを切る）
- 開発
- レビュー レビュー依頼はチャットのBotに出す。 PR内で注意点をいれてmention
E2Eテスト
E2E（End-to-End）テスト
システム全体が正しく動作することを確認するテスト。UIの動作・裏側API・バッチも含めてのテストと言うことか
headlessテスト(自動テスト)
- 本番リリース
QAブランチ
専用branchにマージしてテスト
CircleCI
任意のbranchへのpushを契機にアクションさせられる
- master branchへマージしたらunitテスト
デプロイbranchにいれたらデプロイ
本番デプロイbranchにpullrequestのリストができる
では、インフラは？
- GitHub,CircleCIに、Chefを追加して運用
- できるだけ運用プロセスを開発プロセスと合わせるようにしている
運用プロセスを開発、インフラと合わせることができると、開発側で構成変更したい時にも入りやすくなる
構成管理変更はChef Recipeに書いてpullrequest
リリースもチャットとcircleCIに残るので、このプロセスに乗るだけでドキュメント手書きしなくても履歴が残る
構成変更後はE2Eテストで大丈夫か確認
構築検証、Serverspecでテスト(circleCI)
レシピを作るところ以外はgithub,circleCI,チャットでインフラ運用できる
- この仕組みにしてからサーバログインすることがなくなりました(！)
Kaizenの行動指針
官僚的にならない (×～さんの許可がないと出来ません)
「権威的にならない」(クックパッド) という言葉で気付かされた
クックパッドのインフラ責任者が語る、DevOpsを成功させる考え方「迷ったら健全な方を選ぶ」～DevOps Day Tokyo 2013 － Publickey
- 受理して許可を出す側の人間は権威的になりがち
- 気づかずそうなってる場合もある
大事なこと
- 開発と運用のプロセスを出来るだけ合わせる
- 開発が運用に参加する敷居を下げる
- やろうと思えば出来るという環境 ** 気軽に構成変更のpullrequest出せる
- インフラエンジニア怖くない ** 開発の人からするとそんなイメージもあるので注意
これ、すごい身につまされる指摘だと思う。 自社の現場にいても分かるけど、質問しにくい雰囲気出しているインフラメンバに、恐る恐る質問しに来る開発メンバという構図は結構見かける。 インフラの立場からして、急な作業依頼とかでイラッとすることもあるのは理解できるけど、開発者の方も事前に伝えられない事情はよくある。 （お客さんや連携先の会社の都合とかはもちろんそうだし、そもそも何かの事情で作業をするときに「インフラで対応が必要」ということまで見えている開発者は少なかったりする。）
セキュリティアップデート
チャットからセキュリティアップデート指示 すごい。
yum --security -y update する旨と、アップデートされる依存パッケージなどを記述してpullrequest
- マージを契機に実行
- ただ、再起動があるものなどは同じように実行はできないので、そこは泥臭くやる。（ちょっと親近感ｗ）
運用課題
- CircleCIがボトルネック
- 開発、インフラ(レシピ)、E2Eテスト 全てここを使うので
- テストとかを早く(軽く？)することで頑張る
- あとはお金で解決(今のところ)
他、使っているSaaSの紹介
Bugsnag
- Crash レポート解析サービス
Error Monitoring & App Stability Management | Bugsnag
Pingdom
- 複数の拠点からhttpのエンドポイントをひたすら監視してくれるサービス
このあたりが参考になりそう。 HTTP監視サービスPingdomについて | 稲葉サーバーデザイン
PagerDuty
- 障害時の通知サービス
- Sensuとの連携可能(カイゼンではsensu利用)
- 少人数でインフラ運用するのによい
EC2はもう不要？Lambdaってなにができるの？
まさにLabmdaって何よ？って状態だったので、概要をつかむために聴講。
登壇者
- Webエンジニア(非インフラ)
- AWS歴2,3年
- Node.js１週間
- Labmdaはまだ業務では使ってない
Labmda概要
イベント発生時コードを実行できる (イベントドリブン型のバッチが作れるかな…でもnode.jsでは)
例）画像をs3にアップロードするとサムネイル画像を作って保存
トリガを設定
- 対応するサービスまだ少数
- S3,cloudtrail,DynamoDB,Kinesis
画面から設定できるのはS3のみ
イベントに応じたコードを設定
- 画面上でコードを書く
- 画面からコードをアップロードする
どちらもManagementConsoleで設定可能 (ここでコード書く人いないと思うけど)
料金
- 使用した分のみ
- $0.20/100万リクエスト
- メモリ×実行時間
- メモリ1GB/秒の使用につき$0.00001667
所感
- サーバ不要でイベントドリブン処理が動かせる、という理解ができた
- まだNode.jsのみなので、良い活用事例などはもう少し後になりそう
- 何に使えるか？
- EC2でcronでポーリングして実行するバッチ処理
- Node.jsのapiで作ってあってs3,ec2にインプットがあるもの
各セッション資料まとめ（by dots.)
イベント情報サイトのdots.さんで資料とレポートのまとめページが公開されました。 参加出来なかったセッションの内容はこちらを参照。
