読者です 読者をやめる 読者になる 読者になる

えいのうにっき

あたまのなかのデトックスを、不定期的に。主に Web 系技術ネタ。

『ISUCON5予選報告会 in GCPUG Tokyo』を聞いてきた! #gcpug

GCP 勉強会

ので、そのメモ! @イベント&コミュニティスペース dots. !

eventdots.jp

概要

ISUCON5 予選 ではサーバとしてGoogle Compute Engineが採用されました。 そこで、ISUCON予選が終わった後に、報告会をします。 ISUCON予選に参加した方も、そうでない方も、お気軽にお越しください。

ISUCON で惨敗した話 by @rrreeeyyy

  • 今日の会場にはどんな人がいるのかな?
    • 1 〜 5 全てに出場している人も!
    • 本線出場者も一人!
  • isucon とは。その紹介
  • 登壇者の出場歴
    • isucon は 3 から参加を続けている
  • 今回の isucon 5
    • 会社の同僚と2人チームで参戦
    • Python を選択
    • 登壇者はアプリと全体を見た
    • 相方には DB/SQL 周りをお願いした
  • 事前準備としてなにをやったか
    • 登壇者チームの最終スコアは 7,8000 くらいだった
    • isucon 4 の予選問題で復習、あとはGCP での手順確認
    • 社内 ISUCON の復習
    • モニタリングとかサーバ作業に必要なツールを入れるやつを作っておいた
      • https://github.com/rrreeeyyy/isucon5-initialize-itamae
      • sysctl, limits.conf の適用とかもこの辺でガッと。
        • (かぜぶろの術?秘伝のタレの適応。)
        • このあたりがネックになることは有り得るので
      • nginx をビルドするやつも
      • これのおかげで開戦後1,2時間が浮いた
  • 方針
    • 大きなアプリの改変はしないようにした
      • 過去の予選ではやらなくても通過スコアに到達してた
      • isucon 4 では実装しきれなかったりとかも
    • 最初にサイトの全機能をいじって把握する
      • コードの理解に助けになった(きがする)
      • 変更したときにデグレったか確認するときにも役立つ
    • レギュレーションの得点計算式をしっかり理解する
      • POST は点数にならないとかリダイレクトは点数低いとか
    • ベンチマークを回して遅いパスだけチューニングするように
    • https://github.com/matsuu/kataribe
      • nginx / apache / rack ... のログ解析機
      • どのパスにリクエストがきてどれくらい遅いか、がわかる
  • 今回のアプリ
    • ISUxi
    • isucon5-qualify
    • 「友達のコメント」の表示が曲者
  • 予選
    • 事前に立てた方針に従って粛々と
    • / が遅い、雑な実装になってたため
      • クエリをチューニングした
      • index を貼ったりもした
    • 遅いところをとにかくチューニングしていったらスコアは 9000 くらいはいける
    • 予選を抜けるには 10000 ちょいいる...
    • 大きく伸び悩んだ、「大きな改変はしない」がアダになったかも...
    • リクエストのパターンもそれまでの大会とは変わってた
      • 去年とかは css とかの static ファイルを nginx で返すようにするだけで結構伸びたが...
      • 今回は css ファイルは1こしかなかったり...
  • 所感
    • 限られた時間で優先順位を付けて対応できるか、が isucon のキモのひとつ
    • いかに当たり前のことが当たり前にできるか。「当たり前」の幅を普段から広げていく必要がある
    • 出るだけならタダだし、色々学べてサイコー
    • 予習復習も合わせて行うと技術的にも色々学べる!
      • (予選に出るだけだとそんなに。。)
    • 「来年は勝つぞ!」
  • isucon in GCP についての感想
    • インスタンス起動が早くて良い!
    • インスタンスガチャが無くて良い!(不公平感がなかった)
    • ssh 接続するまでのセットアップが少なくて良い
    • ベンチマークが安定して稼働していた
      • ベンチマーカへのリクエストに応じてインスタンスの増減をさせていた、インスタンスの起動がはやい GCE ならでは。
      • 去年までの AWS だったときは、これがまた不安定だった
        • 【2015/10/07 15:09 追記】GCE のインスタンスの起動が早い点を活かして、キューに応じて都度インスタンスを起動しベンチを掛ける、という仕組みが、待ち時間を短く実現できた、という文脈。去年までの AWS だったときとはアプローチも違うので、「AWS = 不安定」とも取れる上記の書き方は不適切でした。下記【※補足】ツイートもご参考下さい。
    • 再起動を繰り返すとディスクが read only でマウントされたりして大変だったことも。
      • ラベルを付け直すと発生しなくなる?
        • ubuntsu 15 でカスタムイメージを作った時だけ発生する問題?
      • AWS の方が枯れてる、地雷が踏み抜かれきってる、といえるところだったかも。

【※補足】

ISUCON予選の課題をGoogle Cloud Platformを全て使って頑張ってみた by @sinmetal

↓これがテーマ

  • 今回は isucon に参加しなかったけどおはなしするよ
  • TOPGATE から来ますた
  • GCP で WebApp を作る、となったときの選択肢
    • GAE
    • GCE
    • GKE(Google Container Engine)
      • 今日はこれについては話しません
  • isucon 5 は「GCE 上に構築されたアプリケーションのチューニング」だけど...
    • 今回は、「このアプリケーションを GCP 全体で本気で殴る場合はどうなるか」のお話をするよ!
  • DB の選択
    • Cloud SQL
      • インタフェースは MySQL
      • 1インスタンス自体は速くない
      • リードレプリカを構築可能
      • MAX 250GB / 500GB、あんまり大規模な利用は想定されてない
      • インスタンスを立てまくってスケールアウトさせる、という手もなくはないが...
    • Cloud Datastore
      • KVS
      • AppEngine 以外からアクセスすると遅い
    • DB in Compute Engine
      • 好きな RDBMS が使える
      • 構築・運用・保守、全部自分で頑張らないといけないけど
  • static contents の配信
    • Cloud Storage で配信する
      • スケールは勝手にやってくれる
      • リクエストが GCE にまでこないので負荷軽減にも役立つ
  • Edge Cache の活用
    • Google のデータセンターがない場所にもたってるキャッシュサーバ
    • これにのせるのは非常に簡単
      • Response Header にセットするだけ! "Cache-Control", "public, max-age=60"
      • age はベストエフォート
      • 明示的に delete できない
      • 料金は Outgoing だけなのでお得
  • GAE
    • PaaS
    • AppServer = コンテナ
    • 言語?
    • GAE を使う場合の DB の選択
      • Cloud SQL
        • やっぱり遅い
        • App Engine からの接続認証をサポート
        • App Engine と同じ Zone で動作する
      • Cloud Datastore
        • GAE のデフォルトの DB
        • 非常に高いスケーラビリティ
        • Query は simple なものしか使えない
        • 集計関数、JOIN はサポートなし
      • Cloud BigTable
        • Datastore の低レイヤもこれと同じ
        • Datastore と比べると高い、速い
        • Query は simple なものしか使えない
        • 集計関数、JOIN はサポートなし
      • DB in Compute Engine
        • Global IP Addr でのアクセスになっちゃう
    • Cloud Datastore らしい構成について
      • Key 設計
        • 意味のある値が Key の方がいい、単純な連番は苦手(auto incriment な id とか、あんまり使わない)
      • タブレットサーバの分割問題
        • Datastore にどんどんデータを登録する際、 Key が近いと同じサーバに登録されることになるが
        • これが一定サイズを超えると、自動的にタブレットサーバが分割される
        • これが遅い
      • pagination が苦手(offset limit が存在しない)
      • 集計は事前に(put する前に)行う
        • カウントアップはシャーディングカウンターに
    • static contents の配信
      • static_dir 指定で Edge Cache にも自動で載せてくれる
    • Memcache
      • KVのシンプルな cache
      • 無料
      • expire のタイミングはベストエフォート
      • session 情報の保存とか
      • API のレスポンスまるごととか
      • Datastore の front として( goon
    • 非同期処理
      • RPC 呼び出しを複数回行うときはそれを非同期に!
        • GAE からは、基本的に全てが RPC(Remote Procedure Call) になる
      • Datastore に join はないので、Kind ごとに
      • Go だと goroutine が使える!

GCPにおけるCloud Traceを使った正しいパフォーマンスチューニング by @soundTricker31

(Cloud Trace のデモをしながら)

  • GAE の RPC をトレースして可視化してくれる、それが Cloud Trace
    • appengine 限定。MVMs もいける...?
    • 有効化することで遅くなることはない
    • 意外にいろんなものを call していることがわかる
  • memcache 見過ぎ問題
    • 速いよね、と、気軽に Memcache を使いすぎちゃってる問題
    • memcache も 数msec と、大して早くはない
  • あまりにも遅い場合は「分析情報」が出るようになった
  • 日次(前日と比較したもの)のレポートも出してくれる!
  • デフォルトで log と連携しているのもいい(duration がリンクになってる)
  • カスタムレポートを作ることもできる!

GCP で完全無停止でデプロイをしていることについてのおはなし、のさわり)

  • GAE のいいところ、 URL に app のバージョンを指定したらそのバージョンのアプリにアクセスできるところ
  • それを GCE と docker を使って実現している
    • version ごとの docker インスタンスを作ってやってる
    • 手前に nginx の docker もいる
    • その nginx の設定でアクセスの振り分けをしてる?
      • GAE 側のバージョンと連動している
      • 1version 毎に 1 conf ファイルが吐かれる...w
    • メタデータサーバも活用

雑魚なのでISUCON失敗した話 by @yodatomato

  • 真の惨敗について
  • 準備
    • isucon 4 の予習
    • AWS 遅くて捗らない...GCE だと捗る!
    • my.cnf は /etc/my.cnf じゃない
    • isucon 4 のベンチは 14000 くらいまで!
    • いける!!
  • 結果、スコア 2000 ...
  • やれたこと
  • 調子に乗っちゃった
    • やはりここでも my.cnf の罠
  • 油断と失敗の原因
    • いろんな作業を並行してやったせいで、パフォーマンスの上がり下がりの要因がわかってなかった
    • メンバーのドタキャンとか
    • Go の実装が使えなかったとか
  • 得た知見
    • GCE, EC2 よりもシンプルに使える
    • 結局自分との戦い
  • 雑兵 Meetup というコミュニティを立ち上げました!
    • 10/28 に第1回やるよー

isucon 5 予選をどう惨敗したか

  • 前職の同期の方2人とチームを組んででた
  • 「Node.js の実装はなくなりました。」
    • これが isucon か、と
  • 開始が1時間遅れたことで
    • 余裕もてた
    • 最初の作業誰が何をやるかを確認できた
  • やはり my.cnf が読み込めないw
    • AppArmor のせい
  • 最初のベンチマーク
    • 初期200点
    • index貼ったり nginx での静的コンテンツ配信したり
    • これで 2000 に
  • 次に redis 化
    • footprints テーブルのデータをもっていってみた
    • 7000 になった
  • 細かい修正でスコアを稼いだ
    • 10000 くらいになった
  • 再起動テストをした
    • 8700 になった
    • おそらくキャッシュがクリアされたことによるもの
      • キャッシュを温めるためのスクリプトを組めば良かったかも
  • さらに細かい修正をした
    • 9700 に
  • 逆転を狙った
    • スキーマ変更には手を出してなかったので、join をなくすための非正規化に取り組むことに
      • comments テーブルに entry_user_id を追加
  • そしたら 250 になった、小学生みたいなスコア...
    • revert した
  • まとめ
    • 楽しかった!
    • 複数人が同じサーバでコード修正するのだめだなと

Activity Report - 2015 Sept - ISUCON5

  • Google 佐藤さんの、Google 社内への ISUCON レポートを紹介!
  • isucon 4 のとき、やっぱりインスタンスガチャの問題は重く受け止められていた
  • 761名の参加者!
  • 90以上のブログポスト!
  • 1700以上のツイート数!
  • Borg というコンテナ技術がインスタンスガチャ問題を低減化している!
    • GCE も Borg の上で動いてる!
  • スタートアップガイドも頑張って書きました!
  • プリエンプティブインスタンス=Borg のプライオリティが低いインスタンス

ツールつくりました

  • ベンチマーカ、Java で書かれてる
  • スコアは自分で計算しなきゃいけなかったので、そのツールを作りました
  • あとでハッシュタグつきでツイートします!

全体的な感想とか

  • ISUCON 、俄然興味が湧いた!
    • 来年の参加はある...?!あるのか、自分...?!
  • ISUCON アプリを GCP で全力で迎え撃つ件、結果が楽しみだ!w
  • なんとなくだけど、同じ GCP ファミリーではあるにしても、GAE とそれ以外は違う扱いにしてあげた方が、結果的により多くの人が幸せになれるのかなーとか思った
    • やはり GAE はあまりにもトガってるというか...
    • 伝説の appengine ja night 復活、とか... :)