アラタナエンジニアブログ

aratana Engineer's Blog

【開発チームの】チューニンガソンって楽しいよね【とある一日】

こんにちは、アラタナの岩切文吾です。

本日は少し趣向を変えて、アラタナ開発チームのとある一日の風景をお伝えしたいと思います。
時は1/17(土) 9:00。がらんとしたフロアに開発チームの面々が集結。
今日は月に一度(の予定)の勉強会の日なのです。

開発チームはメンバーの知識・技術向上にも力を入れています。
定期的な勉強会もそのひとつ。
この日の勉強会のテーマはチューニンガソン

09:00 レギュレーション発表

まずは会議室に集まり、レギュレーションとチーム分けの発表が行われます。

レギュレーション

  • 3人×4チーム対抗
  • リミット17時
  • 最後に成果を発表すること
  • 対象は自社パッケージ「カゴラボ
  • 大量商品データをスマートに操ること

以上。

要するに手段は特に問わない、と。
エンジニアシップにのっとり、正々堂々と勝負することを誓います!

f:id:bungo_aratana:20150121205213j:plain
緊張した面持ち(背中)の面々。一緒に走ろうね〜

09:30 現状把握

まずは顔合わせ!…といっても普段から一緒に仕事している仲間なので特に何もなく。
チューニンガソンは時間との戦いでもあります。
とはいえ急がば回れ。まずは落ち着いて正しく現状を把握し、問題点を洗い出すことが勝利への近道となります。

f:id:bungo_aratana:20150121210836j:plain
あいさつもそこそこにPCに向かうメンバー。時間無いんじゃ!

10:30 方針立て、役割分担

現状把握が済んだら、次はチームとしての方針を立て、役割を分担します。
限られた時間で結果を出すためには、メンバそれぞれに適切なタスクを割り振ることが大切です。
これは通常のシステム開発…というかどんな仕事にもいえることですね。

このあたりからチーム毎の動きに差が出てきます。
過去の経験からアプローチするチーム。
実装方法から見直すチーム。
まだプロファイラとにらめっこしているチーム。
ここでの動きが結果に差をつけるポイントになりそう。

f:id:bungo_aratana:20150122142722j:plain
リモート(福岡)から参加するメンバーを交えたMTG。遠く離れても空はつながっています。

13:00 チューニング!!

お昼休みを挟んで、いよいよ本格的なチューニングを開始します。
やることは午前中ではっきりさせたので、ここからはメンバーそれぞれがプログラムとじっくり向き合います。
1時間毎にMTGを行い、それぞれの作業が方針からブレていないかチェック。

f:id:bungo_aratana:20150121221019j:plain
モニターに向かう顔つきは真剣そのもの。やっぱりこの時間が一番楽しいな〜

16:00 成果発表準備

アッーと言う間にこんな時間に。
ここまでの成果をまとめ、発表用のスライドを準備します。
焦りからかにわかにザワつくフロア。
写真を撮るヒマもありません!

17:00 成果発表

良いエンジニアに不可欠な素養。それは伝える能力
アラタナの勉強会は成果発表まで、がモットーです。
まあ、当たり前ですよね。

f:id:bungo_aratana:20150122134225j:plain
意気揚々と発表する岩切。偉そうに…

f:id:bungo_aratana:20150121223330j:plain
これは良い例。スマートなプレゼンは絵になりますね。

18:00 運命の結果発表!

そういえば結果発表してない…

やったこと

ここまで書いたところで、ここが技術ブログだということを思い出しました。
申し訳程度ですが、今回各チームでやったことをまとめて列挙します。

  • 不要な処理の見直し
    ベーシックな手段ですが、大事なことですね。
    特にパッケージ製品は基本的に汎用性をもたせるため、ある程度冗長なつくりとなっています。
    汎用性とパフォーマンスのバランスをみて、適切な落としどころを考えるのがまた楽しかったりします。

  • SQLクエリの改善
    大量データを扱う場合、クエリの最適化は本当に重要です。
    負荷テストやってますか?ちゃんとEXPLAINはかけてますか?
    将来を見据えたテーブル設計、クエリ設計を意識しましょう。

  • PostgreSQLインデックス最適化
    こちらも当たり前と言えば当たり前ですが、逆にやっていないと運用開始後に大変な目にあうことも。
    B-treeやR-tree等、各インデックスの特性をきちんと理解していますか?
    僕は理解しきれていません。

  • 商品一覧を遅延読み込みに変更
    先に静的部分を表示した後、ボトルネックとなっている部分をJavaScript等で取得し表示するというテクニック。
    実際は速度が変わらなくても、体感速度を向上させるというアプローチです。
    最近はすっかりおなじみですね。

  • テーブルのパーティショニング(レンジパーティション
    項目値の範囲に応じて、格納先のテーブルを分割する手法。
    今回のチューニングでは逆に検索効率が落ちるという結果になりましたが、使いどころを見極めて効果的に使用したいところ。

  • KVS型でのデータ管理に変更
    商品データをKey-Value Storeで保管、検索エンジンElasticsearchを使用してゴニョゴニョ…というやつです。
    テクってます。

チューニング結果

それぞれのやったことを総合した結果、以下のように商品一覧取得の処理速度が改善しました。

単位:sec

チューニング前 チューニング後
商品一覧 1.2562 0.0174
検索窓「空欄」で検索 1.2153 0.0186
検索窓「商品」で検索 1.2333 0.0183
カテゴリ検索(階層浅い) 1.2335 0.0221
カテゴリ検索(階層深い) 1.2331 0.0187
表示件数変更:16件 1.2535 0.0175
表示件数変更:48件 1.3974 0.0451

f:id:bungo_aratana:20150122161650j:plain

チューニンガソンを終えて

面白かった! ただ、もっと色々やりたかったー…ってのが本音。やっぱり、もう少し時間が欲しかったです。
Webサーバを変えたり(nginx)チューニングしたり、CGIの動作方法を変えたり(FastCGI)チューニングしたり…など。
その領域に行く前にタイムリミット、といった感じでした。

また今回、ガッツリチーム開発をやってみて思ったことは、この短時間でも個人間やチーム間で個性が出るなーということ。
同じテーマでもチーム毎に様々な視点やアプローチ方法があって、一人では気付けない新たな発見がたくさんありました。
アラタナの開発チームは基本、それぞれが独立して動くことが多いのですが、こういった横のつながりをもっと大事にしたいと思いました。

お疲れ様でした!!