humangas's blog

自分用のメモなので雑です。

2013-08-02_JAWS-UG東京-第17回-AWS-User-Group-Japan-東京勉強会に行ってきた

f:id:Humangas:20131228165333p:plain

テーマ

  • ギーク向け勉強会

開催概要


活動

  • JAWS-UG: 38支部

SQS vs SWF

  • なぜ、乗り換えるのか?

SQS とは?

  • メッセージングサービス
  • 送る側も受け取る側も環境関係なし(オンプレだろうが、EC2だろうが)

SWF とは?

  • ジョブワークローサービス

なぜ、SQSを辞めるのか?

  • 辞める理由: → SWFだと解決してくれる
  • 同じメッセージを複数台のサーバが受け取ってしまう。
  • visivility timout の問題で実行終了がわかりにくい = メッセージの削除で判断していた
  • ログ管理が大変(というかログがない)

SWF より、SQS のほうが良かった点

  • 開発がシンプル
  • Latency が少し小さい
  • 安い

SQS 時代のアーキテクチャ

  • 分散ハッシュテーブルを用いて、どのEC2に対してどのキューを見に行くのかを管理するのが大変だった。

SWF 時代のアーキテクチャ

  • まぁ、綺麗に組める(DynamoDB なんかも活用する)

SQS 時代のスケーリング

  • なんか、すげぇ工夫が必要だった(CloudWatch活用)

SWF 時代のスケーリング

  • DynamoDB とCloudWatch を利用してECUの管理だけで全体の処理能力を管理できている。

まとめ

  • とにかく、SWF のほうが、ちょっと高くなるが、管理や制御が綺麗に設計できるんで楽ちん。

コスト

  • 1 - 3億 リクエスト/月
  • → $50 - $100/月
  • 300万 workflow executions/月
  • → $360/月
  • workflowの実行に対して金がかかる(良く動けば金がかかる)

こんなとこにもCDP

  • 小島氏@ADSJ
  • 普段の生活をAWSに例えるw
  • AWS Sumit Tokyo 2013 の 1Day → 2Day への段取り変更をCDPで例える

Amazon の標語


ラピュタで学ぶAWS

  • たきおか氏@サーバワークス
  • バルスコマンド(balus) 作ってきた
  • バルスコマンド(balus): 全てのEC2インスタンスをTerminate する
  • 予想通りw
  • 後ほど、GitHub にうpされる予定
  • 他、シータ、パズーなどのコマンドも用意されている。

DevOps + AWS

  • 「入門 Chef Solo」の著者 であり、元はてなCTOの伊藤直也氏 のセッション!!
  • DevOps = 運用(構築・設定)自動化 → 考え方
  • 資料:DevOps + AWS

Packer

  • AWSで言うところのAMIを統合的に作れるツール
  • CLIで、AMIをバカっと作れる  
  • 言語: Go
  • Packer のprovisioners で、予めChef 入れたAMI作ったりできる。

Vagrant → サーバ構築・起動・停止自動&Chef連携

  • 仮想環境のフロントエンドツール
  • 言語: Ruby
  • Chef 連携あり → Vagrant provision で、Chef レシピまで動かしてくれる。

Chef → サーバ設定も自動

  • Chef → 冪等性(考え方が最高!)
  • で、Vagrant とかで基本サーバ環境立ち上げたら、後はChefでサーバを料理する(cook コマンド)。
  • 言語: ruby
  • サーバ側のOS選ばない
  • 裏側のOS特有のパッケージ管理ツール(e.g., yum, apt)実行も抽象化してくれる

severspec → サーバテストも自動

  • で、Chefで構築までしたら、動作確認も自動化でしょう! → ということで、テスト自動化ツール。
  • 日本人の宮下剛輔さんという人が創ったモンらしい。
  • 言語: ruby
  • rake spec で自動テスト

Guard → ファイル書き換えたら自動でテスト

  • ビルドと同時にテストも走る。みたいな感じ。
  • もう、全自動て感じ。。

で、最後もコマンド一発で全部綺麗にする

  • $ vagrant destory
  • これで、課金もされない。もう安心。

で、さらに実行まで自動でやらせてまう!

  • さらに、これら一連の流れを、Jenkins氏 に実行させる!
  • destory までやって、動くなら絶対動くと言い切れるでしょ。
  • 環境作って、再起動したらサービス起動自動化とか設定してなくて動きませんでした。とかもう無いです。
  • → それらを自動でビルドの度に自動でやれれば、もう安心しかない!!

ここまでで気づいたと思いますが、インフラが全部コードだったよね?

  • ソースコードだと言うことは。。。
  • 最近は、GitHub とかにだいたいみんな挙げててコードが共有されている。  

で、共有されているソースをまた誰かが良くする(pull request)

  • pull request で来た修正依頼とかは、どんな変更がいつあったのか全部分かるようになってるし、戻したりも簡単。
  • さらにそのソースを、コミッターがいちいち全部動作確認までしなくても、テストまで自動的にやってしまう!
  • pull request builder(Jenkins プラグイン)で、pull request コードのテストまで自動化
    自動で、Jenkins がpull request ソースに対するテストまでしてくれる。
    pull request を受け取った側は、コードだけ見ることに集中してテストは通ってるならコッチでどうのこうのはあんましなくてOK = 楽

まとめ(事実)

  • インフラは全部ソフトウェアになった。
  • サーバの変更は、ボタン一発で全自動でできちゃう。
  • → ただ、chefるだけがDevOps ではありません。

まとめ(伝えたいこと)

  • AWSで折角ハードの制約が無くなったわけだし、なるべくソフトウェアで楽しましょう。
  • 楽 = 作業負荷が少ない and 楽しい
  • CI(e.g., Jenkins) や Social Coding(e.g., GitHub) のような、レイヤの高い運用プロセスまで昇華させてなんぼ
  • → 最終的には、この楽さが、ビジネスに良いインパクトを与えるのがDevOps の目的

AWS上にゲームサーバを建てる

  • zynga
  • アメリカ合衆国カリフォルニア州サンフランシスコに本拠を置くソーシャルゲーム会社
  • splunk
  • ログを中心とするマシンデータから必要な情報を見つけ出す検索ツール

AWS Bad Knowhow カンファレンス

  • 荒木氏@ADSJ

バッドノウハウとは?

  • ソフトウェアを使いこなすことができないために渋々覚えた類のノウハウ
  • 2003-03-30 高林哲

奥が深い症候群

  • マニア的に本質とは関係ないところを調べる(e.g., Chefのソース読んじゃう) = どうでも良いこと
  • どうでも良いことに、のめり込んで、本来の目的を忘れている。
  • そういう私も、昨日Chef のソース読んでましたw
  • → 気をつけとかないと、陥りがち。

バッドノウハウからグッドラッパーへ

  • バッドノウハウをグッドラップして、あんまいらんことは気にせずに良い物だけ触って、本質を追いかけよう。

CDP アンチパターン

  • → 豊富なバッドノウハウが無いと、有用なCDPは生まれない。
  • これらが、ヒエラルキー型になってる。
  • CDP
  • アンチパターン
  • バッドノウハウ
  • システムの海

AWSバッドノウハウカンファレンス 2013年吉日開催予定

  • ということで、みなさん、バッドノウハウをもっと共有しましょう。来てね。

以上です。

だけど、こっちのほうが詳しく書いてあるので、オススメなんですけどね。。。
第17回 AWS User Group – Japan 東京勉強会に参加してきた #jawsug

広告を非表示にする