水深1024m

技術的なメモとか日記的なもの

MSPJ マイグレーションコンペティション2015fall に参加してきた

MSPJマイグレーションコンペティション2015fall というイベントに出場してきました。 かなり古いシステムがオンプレっぽい環境にあるのでクラウドにいい感じに移す、というコンペティションです。 参加して敗北したのですが、初回ですし次回もぜひ開催いただければと思っているので、どういう感じだったかまとめたいと思います。

ルールやチームについて

やることは上述しましたが “古いシステムをいい感じにマイグレーションする” です。 イベントページから引用しておきます。

- お題: いま動いているふるーいシステムをバージョンアップしてね
 - できれば利用者に影響なしでやりたい
 - できれば冗長化したい
 - できればさくさく動くようになると嬉しい
 - できればプロビジョニングコードが欲しい
 - できればサーバに関する資料があると嬉しい
- 実施した内容と結果については報告してくださいね
- 背景という名の発注者の弁
 - もうすぐサポート切れるって言うし、セキュリティが心配だし、でもそんなにきちんと管理する手間もとれないし、わかるひともいないし、今のうちになんとかしておきたいんだよねー
 - あんまり何回もいじりたくないから、できるだけ長く使えるようにしてほしいなぁ

当日配布されたお題もほぼこれと同様の内容でした。 チームは当日編成されるので、あらかじめチーム組んでおいで出るみたいなことはできません。

参加者は30歳以下という縛りがあったこともあり、20代のエンジニアが幅広くという感じでした。僕のチームも社会人3年目、3年目、2年目というチームでワイワイしてました。
Slack に運営との連絡用 private chat ができ、僕らは GitHub の private repo に issue などを立ててメモを書いたりするという感じで進めました。 制限時間は10:30 過ぎから 17:00 までの6時間ちょっと。

初期環境

初期環境とさくらのクラウドのアカウント (後述) が渡されて競技開始です。お題はみんな大好き wordpress でした。
使われていたのは CentOS 5.x で、 PHP 5.1 と MySQL 5.0 の環境。PHP が古すぎるので wordpress アップデートもできないし、MySQL も特に設定はされておらず MyISAM のテーブルがあるだけという状況。
また、チームごとに teamN.example.com という単位で DNS のゾーンが分割されていて (ドメインは例です)、その NS を担う bind が立っていました。 始まって30分くらいで大体の状況は把握して新環境の設計をざっくり作り始めました。

設計

使えるサーバ台数などに特に制限もないクラウド環境だったこともあり、いわゆる普通の3層構造を当初作ろうかと話していました。
が、依頼者の背景に “趣味と実益を兼ねて作っているブログ” という話があり、お題にあるようにあまり弄りたくない、きちんと管理する手間も取れない、ということでサーバ台数とコストを抑える (ただし “できれば” の部分はできるだけ満たす) という方針で最終的には作っていました。

移行

初期環境と同時に、さくらのクラウドのアカウントを渡され (好きに使って良いとのことだった) これを使って新環境を作っていきます。 さくらのクラウドをまともに使うのははじめてだったので、とりあえずドキュメントを読みながら石狩リージョンにルータ+スイッチを作り、新環境の App サーバと DB サーバ (設計方針変更により最終的には1台に統合された) を作ります。 サポート期間が長いものを、というところと、チーム的に手に馴染んでいそうということでディストリビューションとしては CentOS7 を選びましたが、個人的には systemd や firewalld がっつり触っているわけではなかったこともあり少しもたつきました。

ディストリビューションが CentOS7 になったので、Apache や MySQL をパッケージからインストールしていけば現代で使われているバージョンになります。 CentOS7 からは MariaDB が標準採用されたという話は知っていたけどチームメイトがインストールしてくれたのは MySQL で、おや？と思ったのですが、さくらのクラウドの public image では rpmforge とか remi とか MySQL community repo とかが最初からインストールされているのですね。へーと思いました。

馴染みの道具は大体揃ったので、旧環境から新環境へのレプリを設定して (wordpress のデータベースだけ)、新環境の App を作っていきます。レプリはチームメイトがいい感じに設定してくれたので、移行先のスレーブを先にガッと InnoDB に ALTER しつつ buffer pool など基本的な設定を入れました。wordpress 本体はそのままコピーして終了。
旧環境でも新環境でも25秒くらいかかるクエリがあってこれはなんだろと思ったら、wordpress のテンプレートタグで SQL_CALC_FOUND_ROWS が使われてるみたいな話があるのですね。移行が第一目標だったので勝手にテンプレート編集するわけにもいかんよな、と思いつつクエリキャッシュが効きそうなケースだったので有効にしたら収まりました。

Web サーバはまあ無難だよねというところで Apache + mod_php になりました。APC も入れたけど先述のクエリのほうが負荷としてはとても高かったので効果は目立たなかったと思います。

新環境の準備が大体できたので、動作確認をしてとりあえず旧環境から新環境に移行していきます。さくらのクラウドでは GSLB が使えるので、そこに切り替えることにしました。

実際に気づいたのは移行よりかなり前ですが、クラウド環境への移行だし DNS サーバは立てずにさくらのクラウドに用意されてる DNS サービスに移せば自前より良いよね、という話を当初していて、いざゾーンを作ろうとしたらゾーンが登録できない旨のエラーが返ってくるというところで少しハマりました。

ドキュメント を読むと、”上位ドメインが当サービスで提供するDNSサーバにNSが向いて” いる、あるいは “上位ドメイン、および下位ドメインが当サービスで既に登録されて” いるものは使えないという記載がありました。

ハッと思い運営の方に質問したところ、予想通り移譲されているドメインの上位ドメインがそもそもさくらのクラウド DNS で既に運用されているとの回答を得た + “具体的に作業内容を伝えれば” その通りに作業をしてくださるとのことだったので、自分のチームに移譲されているドメインの NS 設定を消して自チームのサービス用ドメインへの CNAME を直接設定してもらいました。(この方法をとったのは我々だけだったらしい)

移行は無事一発で済んだので、旧環境からのレプリ設定などを消したり後始末。これで旧環境には用がなくなりました。ここまでで残り1時間30分くらいだった気がする。

冗長化

チームメイトが既に東京リージョンにもサーバを作っていてくれていたので、ネットワーク設定などをざっと入れつつアプリをコピーし、データベースは石狩リージョンに向けました。スレーブは東京リージョンのサーバにもありましたが、このフェイルオーバーまでは作りきれずドキュメントだけ書いておこうという方針になりました。
さくらのクラウドのスイッチはリージョン間接続ができるので、東京リージョンと石狩リージョンの間で L2 ネットワークを結べて便利でした。 GSLB に東京リージョンのサーバ IP を書いたので、これで「石狩が落ちると手動で切り替える必要があるけど東京が落ちても耐えられる」構成となりました。 かなり不完全ですが。。。

プロビジョニングスクリプト

当初は普段使っているItamae などでできる限りスクリプトを作るか、という話をしていたのですが、時間が足りずここは諦めることにしました。 ISUCON などで「プロビジョニングスクリプトから作っていると大抵時間がなくなって崩壊する」というのはわかっていたので、最初から手を付けず、あとから諦める判断だけしたのは良かったと思います。

終了、そして敗北

そうこうしているうちに時間は16:30と終了寸前。チームメイトがかなりきっちりしたサーバ資料を書いていてくれていたのでそちらは完全に任せきりで、こちらはざっくりと技術的な改善点や移行時の手順をメモとして残しつつ、忘れられていた運営チェック用アカウントの作成と疎通確認、再起動耐性の簡単なチェック (実際再起動している時間はなかったのですが) などをしていました。再起動耐性については特にどこにも書いてなかった項目ではありますが ISUCON のトラウマみたいなもので…

17時までに Slack 経由で資料を提出して終了となりました。 懇親会はピザや寿司やお酒などをいただきつつ、チームの構成などについて話して盛り上がっていました。

懇親会も半ばとなったところで結果発表。残念ながら我々のチームは入賞を逃しました。

講評

講評では、”MUST 要件をちゃんと考えて適切な作業やコミュニケーションをしよう” というもっともな話がまずあり、そもそも移行に失敗した (旧環境から NS を移すのを忘れていた？) チームがかなり多かったこと、移行成功したのは数チームであったものの、我々のチームは1つだけ書き込みのテストをしたテストデータが残っていたことが入賞を逃した理由として説明されました。 移行プロジェクトということで、確かに移行したアプリに勝手にテストデータ書き込まれてそれが残ってたら怒られるのはもっともだなーという感想を得ました。アプリを書き換えないという選択はしたのにテストデータはスルーしたというのも甘かったですね。。。

ただ、他チームの話を聞いている限り、ゼロダウンタイムでの移行 + 不完全とはいえ冗長化 + パフォーマンスチューニング + ドキュメントの作成、を達成したのは我々のチームだけのようでしたので、正直かなり悔しかったです。

これがなかったらおそらく優勝していたであろう内容だったので、トップスコア fail した ISUCON5 と同様、最近詰めが甘いことが多すぎるということへの反省と力不足を痛感しました。

最後に

ISUCON 同様、時間が限られた中、チームで何らかの作業をすることは、技術スキルや優先度の判断など個人の能力に加えてチームワーク(というかコミュニケーション)もかなり重要になるので、個人的にはかなり良いトレーニングになるなと感じています。チームがランダムということで若干の緊張感はありましたが、チームメイトもとても良い方々で、バランスの悪いことなどに対してお互い指摘が入れられるような形で作業が進められたのはとても良かったです。

また、さくらのクラウドをほぼ初めて使わせていただいたのですが、普段 AWS や GCE などを触っているとあまり考えることのないレイヤを触っていく必要があり、「ネットワークを作っている」感が強いなーと感じました。このあたりは、求める抽象化の度合いやコスト感 (金銭的なものだけではなく) によって他社クラウドと住み分けがされていくのだと思います。 個人的には、NIC の付け外しがオンラインでできたり、マネージドな DHCP サーバがあったりすると嬉しかったです。

長々と書いてしまいましたが、自分と同じくらいの世代のエンジニアと交流でき、かつ個人的にかなり反省するところもあり、色々と学びがありました。 運営いただいた日本MSP協会のみなさま、ありがとうございました。次回開催も楽しみにしております。