1. オンプレミスから
クラウドへの移行の実際
【完結編】
Cloud on the BEACH 2013 in 沖縄 前夜祭
2013年04月26日 @k_nishijima
13年4月27日土曜日

2. @k_nishijima
自己紹介
西島 幸一郎 / にしじま こういちろう
twitter : @k_nishijima
JAWS−UG沖縄の副代表、
やらせて頂いてます。
一応AWSのプロ
SolutionProviderOnTheBeach.com
13年4月27日土曜日

3. @k_nishijima
昨年11月に発表したこれの完結編
13年4月27日土曜日

4. @k_nishijima
無事(?)、完全移行完了しました
移行元ハードウェア：
✤ 1ラック（サーバ9台、NAS1台）
移行先AWS（もちろんVPC）：
✤ 常設 EC2インスタンス × 2 + スポットインスタンス
✤ 常設 RDSインスタンス × 3
✤ 別リージョンで稼働していた4→2にして同居
13年4月27日土曜日

5. @k_nishijima
インスタンスの数は
随分減った様に見えるけど・・・
13年4月27日土曜日

6. @k_nishijima
当然、もろもろ手間も
かかりました。
13年4月27日土曜日

7. @k_nishijima
構成はこんな感じ
13年4月27日土曜日

8. @k_nishijima
色々はまりどころが。。。
NFS代替
新規実装
SMTP代替
JMS代替
SMTP代替
バージョン移行
全体として疎結合
13年4月27日土曜日

9. @k_nishijima
ひとつひとつ、
地道に潰して行きました
13年4月27日土曜日

10. @k_nishijima
あまり問題なかったところ
JMS→SQS移行
SQSに
ロングポーリングが
付いた！
13年4月27日土曜日

11. @k_nishijima
あまり問題なかったところ
作業中の昨年11月に実装されたので
さほど苦労せずローコストで移設完了
→『#AWSあるある』パターン
13年4月27日土曜日

12. @k_nishijima
あまり問題なかったところ
MySQL4.0（しかもShift-JISおえぇ！）
→ Amazon RDS for MySQL 5.5.x
結構死ねたが、AWSあまり関係ないので詳細は省く。
色々技を駆使して移行完了。
13年4月27日土曜日

13. @k_nishijima
あまり問題なかったところ
NFS → Amazon S3
すべてのファイルアクセスをS3向けに書き換え
ブログ書いた「JavaのURLクラスでS3プロトコルを
実装するときに気をつけること」
実際はURIスキームね
「s3://foobar/key/...」
13年4月27日土曜日

14. @k_nishijima
問題ないと思ってたのに…
SMTP → Amazon SES
アプリからはAPIを直接、各種デーモン用
はMTAをpostfix → exim4 に変えて
さくっと移行完了。
の、つもりだったのが！
13年4月27日土曜日

15. @k_nishijima
移行作業真っ最中、
メールが届かない問題発覚orz
13年4月27日土曜日

16. @k_nishijima
具体的には
『SESではZIPファイルを
添付したメールは送れない』
ええ、認識不足＆テスト不足ですよ
ゴメンナサイm(_ _)m
13年4月27日土曜日

17. @k_nishijima
ドキュメントをよく読もう
http://docs.aws.amazon.com/ses/latest/DeveloperGuide/mime-types.html
SESでは↑にあるファイルしか添付できない。
フォーラムでも定期的に炎上してるけど、
対応する予定は全く無いっぽい感じ。
なんか発想がおかしいとは思うけど
『スパマーには使わせないぜ！』
っていう強い意志？
13年4月27日土曜日

18. @k_nishijima
さてどうする？
結局、メール送信時にZIP添付ファイル
があるときだけ、別のSMTPサーバを
叩く様にコード修正。
また無駄なコードが増えた。。。
13年4月27日土曜日

19. @k_nishijima
その他にも
元々、各コンポーネント自体は疎結合。
しかし、今まで1ラック/1∼2つのHUBだっ
たのが、複数のサブネット/複数のデータ
センターに配置されたので、
ネットワークを経由する分の遅延が
それぞれ間にちょっとずつ増えた。
13年4月27日土曜日

20. @k_nishijima
「なんか遅くなったよね」
というクレームを頂くorz
13年4月27日土曜日

21. @k_nishijima
すみません、
すみません、
本当にすみませんm(_ _)m
13年4月27日土曜日

22. @k_nishijima
今は大丈夫（なハズ）です
• キャッシュしなくても「遅いと体感できなかった
部分」にキャッシュを追加
• 無駄にDBにクエリをかけていたところを削除
• その他ミイラ取りにならない程度にリファクタリング
で、従来と変わらない程度のパフォーマンスに
13年4月27日土曜日

23. @k_nishijima
ハマる話ばかりじゃつまらん
クラウドっぽい、格好いい(?)ところ。
ここですよ
ここ！
13年4月27日土曜日

24. @k_nishijima
ハマる話ばかりじゃつまらん
masterがworkerのライフサイクルを制御。
workerはインスタンス起動後、
自分のアプリをS3から取得してから、
キューをチェックしてバッチ実行。
→ それなんていうCDP！？
13年4月27日土曜日

25. @k_nishijima
もちろん自動で止まる
workerは決まった時間に決まった数
起動し、キューが空になったら終了する。
1. worker：キューが空になりました。自分の作業も終わったんでヨロ
2. master：そか、じゃまたね（API経由でshutdown）
（今は）オートスケールはさせないけど、
キューを監視し、バッチ完了想定時間内に
間に合いそうもなければworker追加
13年4月27日土曜日

26. @k_nishijima
このへんはAMIの作りとAPI
AMIはUser Dataにスクリプト書くとか、
cloud-initを使うとか。
APIからは当然、ほぼなんでも
出来るのでお好きな様に。
（※時々SDKにデグレが入るから注意ね！）
13年4月27日土曜日

27. @k_nishijima
ありがとうございました！
13年4月27日土曜日