サンフランシスコ49ersによろしく

2015/12/15

Kenji Kikuchi

はじめに

こんにちは、サンフランシスコ1年目 TechOpsチームの菊池研自です。
このエントリは GREE Advent Calendar 2015、15日目の記事であり、今年私が六本木オフィスからサンフランシスコオフィスに異動して覚えた戸惑いを綴っています。

サンフランシスコ49ers

サンフランシスコ49ersは、私の住むカリフォルニア州のベイエリアにあるアメリカンフットボールチームの1つだ。サンフランシスコ49ersのチーム名の由来は、1848年にサッターズミルという地域で金が見つかり、その1年後の1849年に金の噂をきいた多くの人々が我先にと採掘に押し寄せたことに由来する。そう、これがカルフォルニアのゴールドラッシュだ。大型の採掘機械のない当時、誰よりも早く現場に到着しいち早く採掘を始めることは、どれだけ利益を得るかに直結する重要な要素であったことが想像できる。

それから長い時間が流れ、ベイエリアはIT企業が多く集まる地域となったわけだが、ここサンフランシスコには取り分けスタートアップ企業が多い。ここに1849年の49ersの精神がどれだけ影響しているかは定かではないが、この地では実に多く人々がスタートアップ企業に魅了されている。「大きく成長した企業に比べて安定感に欠けたとしても、会社が成功すればたちまちストックオプションを現金化して大金持ちになれる。」という考え方があるからだ。やり直しが効く若い世代であればよりスタートアップに挑戦する価値があるだろう。

スタートアップ企業

さて、これが私たちソフトウェアエンジニアの職場にどのような影響をもたらすかというと、早いサイクルでのエンジニアの入れ替わりとスピード感あふれる作業だ。エンジニアは技術パラダイムのシフトや法令の改正、または何らかの環境の変化があれば、チャンスがあると思ったスタートアップ企業にいち早く飛び込んでいく。そうでなくても所属企業の成長に陰りが見えれば新たな可能性を求めて飛び出していく。また、システム作りにおいては、失敗することはあるにせよ、それを恐れずに新しい仕組みやサービスを次々と実現しようとする作業スピードには目を見張るものがある。ここには「早い段階で早く失敗することで人よりも早く成長しよう。」という発想がある。これが、このベイエリアで魅力のあるサービスが次々とリリースされる理由かもしれない。

しかし、この早いサイクルでの人の入れ替わりとスピード感あふれる作業がもたらす結果が、必ずしも優れているかと言えばそうではない。私がこれまで東京で所属した企業や部署であれば、様々な設計やテスト、そして実作業に多くの記録を残していたし、もし同僚が退職するようなことがあれば必要な時間をかけて確実に引き継ぎを行うという姿勢があった。しかし、ここでは1、2ヶ月前に共に作業をした担当者に連絡を取ろうとしたことで既に退職していることが分かったり、つい最近動作し始めたシステムの担当者が数週間後には退職していることがある。理由を聞いて返ってくる定番のフレーズはこれだ。「◯※■△に断り切れないチャンスがあって…。」この◯※■△には大抵の場合スタートアップ企業の名前が入る。

スピード感あふれる作業

スピード感あふれる作業については、例えばこのアドベントカレンダー投稿の話をもらった週にはこんなことがあった。

1. オートメーション漏れ

「チャットサービスのレスポンスが悪いんだけど見てくれる？」知らないシステムだ。エンジニアの入れ替わりが早い為、こんな要求は日常茶飯事だ。報告があった時点で分かっていることは、アプリケーションサーバの応答が遅く、ロードバランサに設定したタイムアウトを超過した順にロードバランサの振り分け対象から外れていくということであった。何が原因でアプリケーションサーバの応答が遅くなっていたかを確認すると、ログファイルより、アプリケーションが接続するドキュメント指向データベースの応答が、イベント開始直前のプレイヤー間のコミュニケーションが活発になる時間帯に限って遅くなることが分かった。

このドキュメント指向データベースが動作するサーバのリソース利用状況と照らし合わせてみると、応答が遅くなる時間帯にユーザ空間でのCPU利用率が著しく増加していることが分かった。要するにこのドキュメント指向データベースは精一杯処理しているのにもかかわらず速く応答を返せなくなっていたのだ。ここまで分かったところでこのデータベースで実行されるクエリの実行計画を確認すると、検索結果に対するソート処理が含まれていることが分かった。ユーザ側で新しい会話を上位に表示するためのソート処理だ。更に調べると、このデータベースには今回問題となっているソート処理に対して有効なインデックスが作成されていなかった。

この問題をまとめると、サービスのリリース直後はインデックスがなくても実行計画の悪さや僅かな応答時間の遅さは表面化しなかったが、プレイヤーが増えゲーム内でのコミュニケーションが活発になるに従って該当のクエリに返される検索結果が増え、これによりソート対象となるデータ量が増えた為にユーザ空間でCPUを派手に使い回しながら処理を進めるものの、インデックスを利用しなければシステム全体から期待される応答性能を満たせない状況になっていたということである。

しかしこれは、このチャットシステムの設計者、開発者には想定できた結果ではないだろうか。想定できなかったとしても、多少のロードテストを行うことでインデックスの欠如が招く事態を事前に確認することができたはずだ。リリース前に十分なテストを行って問題を表面化させることで、インデックスの作成までシステムに組み込むことができたはずだ。この件が原因でプレイヤーのゲームに対する印象が変化することはなかったのだろうか。システムを完成させるまでのスピードは一体どれだけ大切だったのだろうか。

2. 未完のアップグレード

「◯※■△テーブルにインデックスを追加をしたいんだけど？」「え？、はい。」いやいや、なぜそれを確認されるのか納得できない。ここではデータベース上でのロックがシステム全体の設計でカバーされそうな時間内であれば、プレイヤーへの影響が少ない時間帯を見計らって変更をかけることが多いからだ。これは「完全に影響が出る可能性を否定できなくても、それを回避する周到な準備をするのではなく、より早く目的を達成してより早く次の課題に取り組もう。」と考えるエンジニアが多いことに関係しているだろう。

該当のテーブルを調べてみると1000万件のレコードが格納されていた。DBAの言葉を借りて言えば、MySQL5.6環境で本番サービス中の巨大テーブルへのセカンダリーインデックスの追加だ。MySQL5.6であれば、ファイルシステム上に作業テーブルを作成しない「inplace」アルゴリズムを利用してロックなしに完了するはずの作業だ[1]。しかし、ぐんぐん進むことが当たり前の世界でわざわざ作業の事前確認をされたことに引っかかり、今回は検証環境で同様のインデックス追加作業を確認することにした。

事前検証をしておいて良かった。対象のデータベースインスタンスに以前MySQL5.5サーバのプログラムで動作していた形跡が見つかり、それを過去のある時点でMySQL5.6サーバのプログラムで動作するようにアップグレードしていることが分かったのだ。これは、時間型カラムのデータが依然としてMySQL5.5のフォーマットを利用していたことから確認できた。MySQLではバージョン5.6から時間型のカラムにマイクロ秒までの情報を保存できるよう仕様が変更されている。これが今回の問題につながっていたのだ。

対象のテーブルにMySQL5.5の時間型フォーマットでデータが格納されている為、インデックスを追加するつもりでALTER TABLE文を実行すると、時間型データのフォーマット変換も同時に実行される状態だったのだ。これを回避する「avoid_temporal_upgrade」システム変数がMySQL5.6.24から導入されているが、利用しているバージョンはそうではなかった[2]。時間型データのフォーマットの変換には旧来の「copy」アルゴリズムを選択される為、MySQL5.6サーバを利用しているにも関わらずリードロックと作業コストの高いデータコピーを伴ってインデックスが追加されるのだ。

検証環境でインデックス追加にかかった時間は35分であった。黙って実行して許されるリードロックの時間ではない。今回は事前に問題に気づくことができた為、サービスへの影響を抑えた方法でインデックスを追加することができた。しかし、MySQL5.6へのアップグレード作業時に、MySQL5.5のフォーマットを持つ時間型データが残されたのはなぜだろう。調査や作業の時間が確保できなかったのだろうか。それ以上に気になることは、どのようにアップグレードしたかという記録や、なぜ時間型カラムのフォーマットをMySQL5.5形式で残したかの議論が見つからないことだ。

まとめ

新しいことに挑戦し早い段階で失敗する。その経験を活かして正しい方向へより早く成長し、より多くの利益を得る。そのために必要となるのが適切なタイミングを逃さないスピードなのだろう。しかし、作り上げたサービスから継続して利益を得るには、目前の機能をいち早くリリースするだけでなく、システム全体の性能、運用の継続性といった非機能面の要素にも配慮するバランス感覚も必要だろう。私は東京の丁寧な作業を大切にしながら、このスピード感に馴染んでみようと思う。

ところで、私の今最大の悩みは、サンフランシスコ49ersの本拠地がサンフランシスコにはなく、サンフランシスコから南に70km離れたサンタクララにあるリーバイススタジアムであることだ。70kmって遠すぎる。東京ディズニーランドがある千葉県浦安市でさえ東京の隣にあるじゃないか。どういうことなんだサンフランシスコ49ers！

参考

[1] 『MySQL 5.6 リファレンスマニュアル』オンラインDDLの概要
[2] 『MySQL 5.6 Release Notes』 Changes in MySQL 5.6.24

明日は、学生時代に将棋で全国を制覇した経験を持つ白浜さんの記事です。お楽しみに！

漫画『ブラックジャックによろしく』からの画像転用において、佐藤秀峰先生に感謝します。