devlove 移行勉強会

2010/07/15

携帯サイトの移行～ピンクのクマさんお引っ越しの巻～

ソネットエンタテインメント株式会社サービス開発部

佐藤洋三

Disclaimerこのプレゼンテーションは、発表者である佐藤洋三の個人的経験・見解に基づくものであり、所属するソネットエンターテインメント株式会社の公式見解ではありません。

なので、大人な対応をよろしくお願いします。

自己紹介佐藤洋三ですひらがなで「さとうようぞう」でぐぐれば、blogとかヒットするはず。

Twitter : yoozoosatoMail: [email protected]

自己紹介2003/04 ~六本木の携帯コンテンツプロバイダでキャラクター系コンテンツを中心にケータイサイト開発に従事データセンター丸ごと移行とかも手がけた

2010/02 ~ソネットエンターテインメント株式会社サービス開発部

Agenda

1.こんなものを移行したっ！2.要件はこれだっ！3.方針はこうだ！4.細かいタスクを説明しよう！5.ココにはきをつけろ！6.理想を追いかけたっていいんだぜっ！7.みんなと移行について語りたい！

1. こんなものを移行したっ！ケータイポストペットパーク　携帯３キャリア公式サイト

(姉妹サイト)ポストペットメール素材　携帯３キャリア公式サイト

(姉妹サイト、iModeのみ)きせかえポストペットお部屋deポストペット

2. 要件はこれだっ！(その１)

既存会員のデータは全て保持ユーザーデータは全て新環境に移行(会員登録状態、購入履歴 etc.)ケータイ公式サイトなので、キーは（所謂）個体識別番号

過去に配信していたデジタルコンテンツも全て(待受画像やFlashなど)移行！全部で4,000点くらい

2. 要件はこれだっ！(その２)

旧環境が使えるのは５／３１まで６／１には新環境切換え必達切り戻し不可。一発で決めれ。

移行元は Apache + Perl CGI + Sybase

ん？災ベース？

それなりに、厳しい。

3. 方針はこうだ！• 移行元の環境は使えないので、新規に作りなおす• Apache + PHP + MySQLで再構成•（所謂、標準LAMP）

• ユーザーデータやデジタルコンテンツのデータは、移行先に合わせてコンバートする

4. 作業段取り（その１）1. 移行先環境構築

• サーバー手配• ミドルウェアのセットアップ

2. アプリケーション開発• 実作業は開発会社に発注した• 私の担当は主にプロマネ

3. 旧環境の<del>リバースエンジニアリング</del>整理、及び確認• 移行元アプリケーションの調査

4. 作業段取り（その２）4. 移行リハーサル

• ユーザーデータの移行は開発会社と調整して模擬移行を実施した

• デジタルコンテンツは、デバッグ用も兼ねて新環境にインポートした

5. 移行本番• 作業手順書を作成• 手順書にコマンドなどを書いておく

6. 旧環境の後片付け

問題が発生した！

バックアップしてくれたチームメイトに感謝！

どうもありがとう！

4. 移行で気をつけるポイント(1)

1. WEBアプリなので、切換えはDNS• TTLを事前に短くしておく• 10日前にやっておけば大丈夫

2. リクエスト元が見えない→要注意• ケータイアプリとか• 外部システムからのリクエスト• <a href=…> が見えないもの

• 某案件では・・・


3. 通信元が判らないなら、ログに残す• 移行が決まった時から、 log = enabled / loglevel = info• 外部システムがブラックボックスな場合、ログしか手がかりがない

• FTPとかMailとか、取れるログは全部取る。ローテートも止めていい。

• 量が多くても、 cat *.log | awk {…} | uniq でOK


6. GUIは極力使わない• 圧縮や転送などの動作を一つ一つコマンドで実行する

• tar -czf ….• scp hoge.tgz remote:~/hoge.tgz

7. コマンドの連鎖を一本のスクリプト化• リハーサル時にスクリプトにする• 演習で上手くいけば、本番も上手くいく。GUIにはその再現性がない。


5. (個人的好みですが) データ可視性重要• 元データから移行先に一発でinsertするスクリプトとかは組まない

• 途中で敢えて「人間が読める」フォーマットを通すことで、トラブル時のリカバリ速度があがる

• おすすめなのは .csv / .tsv• エクセルで開けば人が読める

5. こういう移行が理想的（１）1. 移行チームに元アプリの開発者が居る

• 「見えない通信」を熟知している人• チームに居なくても「すぐそこに居て、質問ができる」だけでも違う

5. こういう移行が理想的（２）2. バックアップ、重要

• データのバックアップではなく、体制的なバックアップ

• 体制面で考えると、、• 平日日中 >>> 平日深夜 > 土日

• DBのLog領域が足りなくて移行直後に障害を出したことがある → 深夜でDBAがつかまらなかった。あんときはマジで修羅場だった・・・。

6. みなさんはどうだろう？

• 「移行」という作業の問題点

移行の準備段階

ゴールが見えない

どこまで調査すればいいのか・・・

この情報ソースは、誰を辿ればいいのか？

ログは3ヶ月分調べ尽くした。が、半年に1回のリクエストとかあったらどうしよう・・・

旧環境のデータの持ち方は、本当にこれで合っているのか？　SQLをもう一度見直した方がいいんじゃぁないか？

元のアプリが出せていた性能を、新アプリで本当に出せるか？

… etc.

移行に銀の弾丸は無い

だが、粒度を小さく考えれば、それぞれのステップで

ベストプラクティスはある。

みなさんの体験した、あるいはみなさんの考える移行についてお話できるととてもうれしいです。

ご清聴ありがとうございました

devlove 移行勉強会

Technology