はてなブックマーク - Fusic勉強会 #2 を開催します
    このエントリーをはてなブックマークに追加

    小山です。

    週末は、大学の恩師のご還暦祝賀会に参加しました。
    個人的に学生最後に印象に残っているのが、研究室送別会の吞み会の場で、その先生に「一生のうちに20人、師と呼べる人を作れ」と言われたことです。その場で「まず一人目ができたんだ」と心の中で思ったのはいい思い出です。

    さて、11月7日に開催したFusic勉強会 #1ですが、無事開催することができました。
    自分は30分枠で、「DevOpsな受託開発」というミーハーなタイトルでまじめに発表しました。

    勉強会の最初としてはいい感じでスタートできたのではないかと思います。これから試行錯誤していきたいと思います。

    勉強会について、いくつかコメントをいただきましたので、回答したいと思います。

    参加しようと思ったら埋まっていたんだけど

    申し訳ありません。これは、Fusic勉強会の特徴である「社員優先」のため、まず社員参加で人数が埋まってしまうのと、使っている会場の大きさから、外部からは少人数しか募集できない状況です。
    できるだけ調整していますが、根本的な解決はFusicの規模が大きくなって会社移転でもしない限り変わりません。
    そういった意味では鋭意努力します!

    告知はどこでしているの?

    このBlogエントリもそうですが(今回は事前告知です)、http://fusic.doorkeeper.jp/ に登録しておくと、ページ開示と同時に告知メールを受け取ることができます。是非ご活用ください。

    雰囲気が固くないか?

    勉強会の部類ではちょっと固い印象がありましたね。これは今後是非とも改善していきたいと思います。ピザとか食べながらがいいんですかね?

    社外参加者の発表枠はあるの?

    はい。今後開催告知と同時に社外発表枠を募集したいと思います。ただ、毎回ではないのでご了承ください。

    懇親会は?

    今のところ、勉強会主催側で設けるということはしない予定です。「懇親会!懇親会!」という方は是非Twitter等でFusic社員にたきつけてみてください。意外なレア社員がでてくるかもしれません。

    というわけでFusic勉強会 #2を11月21日に開催します

    今回は、Blogにて事前告知していますので、参加してみようかな?という方は、是非 fusic.doorkeeper.jp/ に登録しお待ちください。申込ページは本日夕方に公開予定です。

    どうぞよろしくお願いいたします。

      はてなブックマーク - RDS for PostgreSQL を早速試してみた!
      このエントリーをはてなブックマークに追加

      Fusic杉本です。こんにちは。
      みなさま既にご存知だと思いますが、AWSが2013/11/14にRDSでPostgreSQLをリリースしました。


      その日と言えば、サー・ポール・マッカートニーの日本ツア福岡公演の日。
      若干AWSのニュースが薄れてしまっていたかもしれません!!!弊社がある福岡市内ではド派手なトラックが走っていました。

      私は先日の会社10周年記念パーティで弊社社長より福岡公演のチケットをいただいていたので、朝からこの2大ニュースでわくわくしてたまらず、筆を取りました。※ライブサイコーでした!><

      なぜこのニュースに胸熱なのか!?

      弊社では、特に“制限”がない限り、PostgreSQLを使用しています。
      理由は社内全員に経験があり、さらに社内のデータベーススペシャリストがPostgresマスターのため、パフォーマンスや複雑な処理が必要となったときに助けてもらえるから(と個人的に勝手に思ってる)です。
      で、この“制限”というのが、お客様の要件というよりも『AWSのRDSでPostgreSQLがないから仕方なく、MySQLを使ってる』という。。。(これも個人的に勝手に思っていることです)

      だからかなり胸熱です!

      ということで、早速Postgres for RDSを試したみました。

      とりあえずインスタンスを起動してみました。


      インスタンスの起動はAmazon Management Consoleから、MySQLのときと何ら変わりません。

      あるある!おなじみの象さん!

      とりあえずいつも通り、ポチポチと進みます。
      AWSブログではver.9.3.0が表示されていましたが、2013/11/16時点では9.3.1しか選択肢がありませんでした。9.3.1が2013/10/10リリースみたいなので、リリースが決まってからデフォルトバージョンもあげたのでしょうか。そのスピード感いいですね!

      ほんと全ての機能が使えるようでした。
      ・・・ようでしたが、Read Replicaは使えませんでした。9系からレプリケーション機能あると思ってたんですけど。

      しかし、バックアップ関係がそろっているだけでもう完璧です!!!
      もうこれでせっせと頑張ってEC2上でバックアップやらデータ領域を別EBSにしたりとか、冗長構成とか、諸々の心配事を楽して解決できますね!
      ※お金さえあれば。

      あとはいつも開発している感じで、さくさくっと動きましたよっと

      とりあえず、pgAdminでの接続とCakePHPで簡単なデータ登録を試してみました。
      vagrant上のアプリからの接続からなのか、e-mobileだからなのか、ケチってmicroインスタンスにしたせいなのかは不明ですが、結構重かったです。
      性能等については、近いうちに調査してみたいと思います。


      ※(左)CakePHPアプリケーションの画面、(右)pgAdminでの画面

      まとめ

      RDS for PostgreSQL胸熱!ってだけの記事でしたが、休みの日に気になって試した程度なのでお許しいただくとして、、、
      弊社は既にAWSコンサルティングパートナーとして多くのシステムをAWS上で構築してきましたが、今後より強みを活かして、開発をすることができそうです!

        はてなブックマーク - ISUCON3の本選にFulabで参加してきました
        このエントリーをはてなブックマークに追加

        Fusic 平田です。
        予選を繰り上げ当選できたので、本選に参加してきました。

        一緒に参加したヌーラボ染田さんのblog記事ISUCON3本選関連エントリまとめあたりも合わせてご覧ください。
        我々が何をやったかの詳しいところは染田さんの記事に書いてあるので、僕の視点から見たことを時系列で並べてみます。

        前日の作戦会議

        「今日は飲んでも飲みすぎない」が最初の確認事項。
        あとは前回の反省で、「事前の検討を長めに」「入れ替えが容易ならやってみて、だめだったら戻すくらいで」といったところを確認。
        とは言え後は複数台構成だろうってくらいの予想しかできなかったので、「立ち合い強く、あとは流れで」みたいな話になりました。
        「地方参戦の強みをおやつで発揮する」というのも協議結果で、これについては後述。

        で、前日の準備にopsletを活用。
        弊社の眼鏡軍曹が作ったもので、ISUCONに合わせて機能追加までやってくれたものです。
        機能としては、curlで標準出力やらファイルの中身やらをぼんぼんサーバに飛ばすもので、



        こんな感じで見れるってやつです。
        手元で試したのとかを送っておいて、あとは当日活用しようってことで大いに使わせていただきました。

        当日朝

        遅れることなく無事に到着。
        写真をいろいろ撮ったりしつつ。


        ~開始前

        PCの準備をしたり、会場を見回ったり、おやつの確認をしたり。
        おやつは生八つ橋とめんべいを用意。


        事前説明など~競技開始前

        既にwktk感が止まらない事態だったのですが、説明が始まってさらにテンションUP。
        で、OPムービーに「画像投稿」と出た瞬間から「これはやばい」感ががが。

        開始~12:00ごろ

        前日の作戦会議どおり、まずは中身を確認。
        のち以下の方針(染田さんの記事からコピペ)。

        ・予選同様フロントは varnish に入れ替えてキャッシュなるべくきかせよう
        ・アプリの外部プロセスでの変換処理がツラいので Imlib2 (or Imager) に置き換えよう
        ・MySQL の timeline 周りの臭そうな所をひとまずつぶそう
        ・いきなり複数台展開するとボトルネック分かりづらくなるから、まずは一台でチューニングして各サーバへの展開は後からにしよう

        なんとなく「上3つを片付けて、ある程度スコアが伸びるのが15時くらいかなー」「それからボトルネックに合わせて展開しつつ更にいろいろ手を出して17時過ぎて、あとは再起動確認しつつ最終調整かなー」とか考えていたんですが、完全に甘い目論みでした。
        自分は前回同様、varnishでキャッシュして捌くところが担当。

        ~15:00

        とりあえず、varnishに差し替える→fail!fail!fail!
        最低限の設定(静的ファイルだけキャッシュ、あとはpass)しか入れてないはずだけどなー。。。と思いつつ、ヘッダの状況とか確認して合わせたりしつつ。
        timelineが30秒詰まってまともに動かない。。。のでアプリ側を見たらsleepとか入ってて、これで眠ってるんだろうなーということで外して再チェック。
        でもfail!fail!fail!で、こりゃvarnishのほうちゃんと見直そうってことで、サーバ2のほうで別途確認を進めることに。
        この時サーバ2を初めて覗くことになったのですが、
        > 残りの4台は社長が追加契約した直後の状態なので、まっさらな状態です
        てなレギュレーションにガクブルしてたらperlとかmysqlとかは入ってたので、思ったより社長は悪人じゃなかった!と一人ほっとした次第です。

        で、そこからいろいろ設定。

        ・ヘッダをもう少し調整してばっちり合わせる
        ・アプリ側でno-cacheヘッダ付加してたなーと思い、念のためつけてみたり

        とかやっているうちにfailは出ないことを確認して、よし画像をーと進めたのですが

        ・ログインユーザごとにキャッシュ分けなきゃーなので、cookieの値を見て、ユーザのapp_keyごとにキャッシュを分ける
        ・/icon/と/image/をキャッシュさせた時のfailが回避できない
        ・変な状態のキャッシュが残りにくいよう(failしないように)頻繁に消すようにして整合性を重視
        → したつもりでもfailするしそもそもスコアが全然伸びない

        と言ったところで詰まって、どうしたもんかなーとか思っている間に15:00。
        アプリ側は、画像変換処理を入れ替えたらどうもfailするとか、timeline部分のクエリを改善すべくfollow情報をmemcachedに放り込むとか、手は打つものの大きくスコアを伸ばすに至らず、memcachedで画像をキャッシュさせる戦略に切り替えつつ、といったところ。
        要はスコアを伸ばせてない状態のままで、「もう15時かー!」と3人で悲鳴あげてました。

        ~16:45くらい

        とは言えこのまま手をこまねいているわけにもいかないので、vmod-memcachedとか持ってきて策を練るも、うまいことキャッシュを操作しようとなると

        ・そのリクエスト+Cookieの値に合わせた値をmemcachedに保持しておく必要がある
        ・となるとアプリにさらなる改変が必要
        ・画像キャッシュする部分も影響受けそうで、改変コストがだいぶ大きい

        といったところで手を付けられない、ぐぬぬ、と。
        そうこうしている間にアプリ側の改修が進み、画像のキャッシュがヒットしだして、スコアが伸びて4000くらいに到達。
        この辺で山本さんに現状の問題をざーっと伝えたところ、「なんかiconは何も考えずにキャッシュさせるだけでよさげ」といった話になり、あーそれならすぐできるな、とさっくり設定して、ついでにサーバ1(アプリ改修を反映しているサーバ)をバックエンドにしてベンチを走らせてみる。



        ( ゚д゚)
        (つд⊂)ゴシゴシ
        (;゚ Д゚) …?!
        思わずガッツポーズしてしまいました。

        ~17:30くらい

        といったところでworkloadを変えたりいろいろ実験してサーバ構成を見直す。
        個別検証だったり、アプリ改修の最中でサーバを分けていたりの経緯で
        サーバ1 -> APサーバ
        サーバ2 -> キャッシュサーバ
        サーバ3 -> 空き
        サーバ4 -> memcachedサーバ
        サーバ5 -> DBサーバ
        といった役割構成。
        DBは余裕綽々だったので、AP/キャッシュサーバを増やす方向で検証を進める方向にシフト。
        サーバ1とサーバ2をAP+キャッシュ(varnish)の同一構成にしてベンチ→fail!fail!fail!とうまくいかず、調査と対応を進める。
        とかやってるうちにLINE選抜が40000超えのスコアを出して、会場が「うわー」「うげー」「うひー」みたいな声で溢れかえっていました。
        僕は「うわー」って叫んだ一人です。
        引き続きvarnishだけ増やす設定進めようとするも、確実に終わらせるには時間的に厳しいので断念。

        ~18:00

        残り時間も少なく、これ以上の手入れは厳しいと判断して、サーバ再起動をしての動作チェックに移行。
        ここはもう3人で声掛け確認をしつつ、「サーバ2再起動しましたー」「サーバ5再起動OKー」みたいな感じでひたすらに確認。
        全ての懸念が取り除かれて最終ベンチを走らせたところでタイムアップとなり、最終ベンチのスコアは11000くらい。ただしfail(時間切れのためと思われます)。

        結果発表待ち中

        終わってみるといろいろ思いつくもので
        ・そういやimagemagickのパラメータ全然変えてなかった
        ・横展開に舵を切るのが遅かったかしら
        ・iconだけvarnishでキャッシュさせる手はもっと早く気付けたなあ
        ・おやつ全然手を付けてなかった→懇親会で配ろう
        といったあたりがすらすらと出てくるんだから困ったもんです。
        また、この後に備えてウコンを仕入れて投入。

        結果発表

        ご存じのとおりLINE選抜が優勝し、#茶番のハッシュタグが乱舞。



        その後、出題者の藤原組長の講評、そして優勝以外の結果一覧。
        計測前のスコアでは7-8位くらいで、「failしなきゃ真ん中よりは上かなー」くらいに考えていたのですが、



        3位!!ということで、予選繰り上げ通過から考えるとかなりのジャンプアップ。
        100万円とダンボーは残念ながら獲得できませんでしたが、きちんと計測完走して上位に入れたのでほっとしました。

        懇親会

        戦いきった後なので、心地よい疲れとともに飲みまくりました。
        ISUCONの話だったりそうでない話だったり、某社某会長の物まねを見せていただいたり、楽しい時間が過ごせました。
        あと、モリスコールを生で聞けたのでよかったです。

        反省とかいろいろ

        予選の時は、何か手を打つ→スコアが上がる、のループをうまく続けられたのですが、今回はなかなかスコアが上がらずに苦戦しました。
        その中で視野が狭くなっていった部分もあり、この辺はまだまだ精進しなければならないなと感じました。
        また、優勝したチームやベンチで高スコア出していたチームは、早い段階で複数台構成を意識して進めていた点が大きく違ったなと。
        当初のもくろみ通りに早めに複数台に展開できていればまた違ったのでしょうが、この辺は自分の実力が足りなくて次の策を打つまでに時間がかかりすぎたなーと反省しきりです。
        一方で、終盤を再起動検証につぎ込んで結果を残せたのは、安定スキーな自分としては満足のいくところです。

        その後

        お祝いということで、社内の方々からいろいろいただきました。



        ありがとうございますありがとうございますどうしてこうなった。

        最後に

        以前から参加したいと思っていてようやく参加できて、ありがたいことに本選まで参加させていただきました。
        当日もずっと言っていたのですが、1日中ひたすら楽しかったですね。
        楽しいイベントを提供していただいたISUCON運営チームの皆様、本当にありがとうございました。
        また、本選に快く送り出していただいた弊社の皆様、ありがとうございました。
        そして、一緒に戦っていただいたヌーラボの山本さん&染田さん、本当に本当にありがとうございました。
        また次回も参加したいとか言い出すと思いますが、その際は皆様よろしくお願いいたします。ぺこりぺこり。