サービスを止めずにDBのシャーディング、gemライブラリを改造――2つの事例紹介
伊藤氏は、XFLAG スタジオにおいてSREグループが実際に関わった事例を紹介した。
まず、DBの水平分割（シャーディング）の事例である。更新頻度が高く負荷が増大したDBを、シャーディングにより8分割することになった。サービスを止めないために新しいシャードを作成し、アプリケーションではデータの更新時に旧DBと新シャードに対して二重に書き込みを行い、さらにスクリプトにより旧DBから新シャードへ既存データをコピー。そしてコピー後に検証を行うといった手順で実施した。19日間かけてコピーと検証を行った結果、14億件のうち、検証で問題があったレコードを10件程度に抑えることができた。
この事例でSREは、サービスを動かしながらデータを二重に書き込む処理やデータのコピー・検証を行うスクリプトの実装を行い、さらにDBのキャパシティプランニング、DB用サーバーの用意、シャーディングしたDBへの切り替え作業、アクセス遮断のためのメンテナンス作業、不測の事態が発生したときの切り戻しの用意などを担当。また、関係各所とコミュニケーションをとり、メンテナンスの説明や調整を行った。
もう1つはキャッシュ活用の事例だ。モンストの構成はmemcachedへの依存度が高く、ユーザーが2回目にアクセスする際、基本的にDBへのクエリーは行われない。そのために複数のgemライブラリと独自のキャッシュ実装を組み合わせて使用していたが効率が悪く、memcached用サーバーの容量を無駄に使って台数が増える、アプリケーションとmemcached間のトラフィックが飽和直前といった問題が発生していた。
SREは容量の効率化とトラフィックの削減を図るため、使用しているgemライブラリの改造を実施。この際、サービス停止を招かないために移行中キャッシュプールを破壊しないように気をつけること、切り戻しを念頭に置くこと、既存のインターフェイスと互換性を持たせること、ライブラリの仕組みは説明するが内部の処理は隠蔽することなどに注意した。ライブラリは作って終わりではなく、使ってもらえなければ意味がない。そのため、ライブラリの機能を使う処理を実装したり、コードレビューで使い方を示したりといったことも行った。結果として、開発者から見ると機能は変わっていないが、内部ではキャッシュのシリアライズ方法を大幅に変えることでキャッシュを効率化し、容量面で約60％の削減を実現した。
あくまでSREがやりたいのは「事業」である
伊藤氏はセッションの最後に、SREグループが大事にしていることを3つ挙げた。
まず、「活用されるものを作る」ことだ。作るだけではその成果は3割にも満たない。機能を安全にリリースし、グラフやメトリックスに変化があって初めて意味のある成果となる。
次に、「自分たちの目標を達成することだけにこだわらない」点。SREのミッションを達成するために、機能追加を行わないのは本末転倒だ。機能がリリースされ、システムが変更された状態で、ミッションを達成しなければならない。そのためには直接的なメトリクスを指定しないなど、KPIの設定に気をつける必要がある。
3つ目は、「SREがやりたいのは事業である」こと。何があってもそれを妨げることはしない。新しい機能によってシステムの負荷が高くなるとしても、「事業にメリットをもたらすものであれば、全力で支える」と述べ、伊藤氏はセッションを締めくくった。
お問い合わせ
株式会社ミクシィ
