MSPJマイグレーションコンペティション2018winterに参加した

2018/01/29

1/27 に MSPJマイグレーションコンペティション2018winter というイベントに参加しました。

MSPJマイグレーションコンペティション2018winter (2018/01/27 09:30〜)

# 日本MSP協会主催マイグレーションコンペティション 2018 winter 日本MSP協会コンペティショングループは、運用技術を競うコンペティションを開催し、次代を担う若手運用技術者同士の交流・競争を通して日本のMSP事業者における運用技術の向上を目指します。日本MSP協会の会員企業に所属していなくても、開催当日30歳以下であれば参加可能です！前々回の様子：http://mspj.jp/event/migcon-2015 前回の様子：http://mspj.jp/event/migcon-2017 # 開催日時 2018/01/27(土) 開場：9:3...

30歳以下の若手エンジニア向けのイベントです。ざっくり内容を書くと、制限時間内に古い環境で動いているシステムを新環境に移設し、その結果と対応の仕方を競うコンテストです。

今回のお題は 「EC サイトの移設」

例年、 Wordpress や Redmine のようなオープンソースシステムがお題に出されるので、同じ会社の先輩と「EC−CUBE あたり出るんじゃね」なんて話をしていたら、マジで EC-CUBE 出ましたｗ (なお予習等はしていなかった模様)

旧構成把握

3人チームで競技スタートです。

まずは、午前中1時間ほどを使って、旧環境で既に動いているシステムの構成把握からはじめました。

インフラ: AWS
- EC2 1台
- Route 53 やストレージ系サービスは利用無し
OS: CentOS 6.9
Webサーバ: Apache 2.2
- Virtual Host で EC サイトと (その EC サイトを運営する企業の)コーポレートサイトの2つを提供
DB: MySQL 5.1
PHP: 5.3.3
EC-CUBE 2.13.5
メール: Dovecot 2.0.9, Postfix 2.6.6

その他確認した項目としては、

authorized_keys の中身
cron ジョブが居るか
セキュリティグループ, 利用しているポート番号

など。

設定ファイル類は (おそらく) デフォルトだったファイルが残してあったので、 diff とって何が変わっているのか確認しました。httpd.conf.org 的なやつね。

Apache の DocumentRoot がホームディレクトリに向いていたり、紛らわしい名前のゴミディレクトリが用意されていたり。conf をちゃんと読んで計画立てないと移行忘れが発生しそうな罠(?)がありました。

移行計画

初めに、チーム内で絶対に実現するべき要件について話し合いをしました。 must な要件として 「今の環境を新しい環境に完全移行して欲しいです。」 が提示されているため、いきなり冗長構成などにはせず、まずは同じシングル構成で新環境上で動作させるというところを目指しました。

OS やミドルウェア類のアップデートは、利用できるパッケージのうち一番最新のものを使うことにしました。

EC-CUBE はバージョン 3 系が出ているため、それもアップデートできないかという話が出てきました。新環境を構築した段階で一度 3 系を動かし、問題が無ければ旧環境のデータを投入 & DB 再構築する計画を立てていましたが、これは失敗しましたｗ

EC-CUBE は 2 系と 3 系で作りが別物らしい情報を見つけた
- DB のテーブル構成も変わるらしい
- DB 移行スクリプトを公開している人を見つけたが…
  - 実際の仕事で使う…?
新環境でそもそも 3 系がうまく動作しなかった
- css や画像素材のパスがおかしくなり、時間内に修正できそうな目処がたたなかった

ということで EC-CUBE のアップデートは断念し、旧環境の EC-CUBE をそのまま持ってくることにしました。

残り1時間とちょっとというタイミングだったので、EC-CUBE アップデートにこだわっていたら、そもそも移行自体が終わらなくなるところでした。まずは旧環境を移設させてしまおうというチームメンバの慎重な意見に救われましたね 🙏

後から振り返ると、「今の環境を新しい環境に完全移行して欲しいです。」 の要件的に勝手にアップデートしてはいけなかったのでは、と思ったり…w

作業分担

僕は Web サーバの構築と DB の dump & import などを担当していました。

メールサーバはチーム内に運用の経験がある方がいたのでおまかせし、Azure の操作と運営への質問などをもう一人のメンバーのおまかせするような作業分担でやりました。

各々出来ることや得意分野で担当範囲がうまくバラけたので仕事はスムーズでした。

移設後の構成

こんな感じになりました。赤字の箇所が旧環境から変更のあった箇所。

インフラ: Azure
- Virtual Machine 1台
OS: CentOS 7.4
Webサーバ: Apache 2.4
- Directory ディレクティブの書き方が変わるので conf 修正が必要だった
DB: Azure Database for MySQL
- MySQL 5.7
  - netcat で疎通確認したとき気づいたのですが なぜか MySQL 5.6.26 と表示されるｗ
  - ブラウザ上では 5.7 なのに
  - 謎い
PHP: 5.4.16
EC-CUBE 2.13.5 (旧から変更なし)
- DB のデフォルトストレートエンジンの設定を1行付け加えた
メール: Dovecot 2.2.10, Postfix 2.10.1

終了30分ほど前で、 DNS 切り替えが完了。その後は新環境の疎通確認や、報告用のドキュメントを書いたりしていました。

結果

残念ながら優勝ならず…

移行は完全に出来たつもりでいたのですが、後々思い返すとツメの甘いところがあったなと…

authorized_keys 移行するの忘れた
DB サーバのタイムゾーンを変更していない気がするゾ
旧 → 新切り替え時に Sorry ページ出してなかったな
- 講評にて「メンテページのステータスコードも意識してね、 200 じゃアカンよね」
- そもそも出してなかったワ
再起動テストしたっけ
- Apache は systemctl enable したがソレ以外は…?

このコンペの特徴として、実際の業務に則した形でお客さんに報告・相談を行ったり、お客さんの権限でしか実行できない作業をお客さんと調整の上実施してもらう (DNS 変更とか) 必要があります。また、運用中のシステムを停止してサービス影響を出してはならない、止める場合も事前に調整を行った上で最小限の影響に留めるなどの配慮が必要になってきます。

我々のチームはその点が甘かったなと。優勝チームのすごいところは、移設を完遂するための技術的スキルがあるだけでなく、丁寧で質の高い仕事ができる、いわゆる「仕事力」みたいなものが高く発揮できていたのではないかなと思いました。

個人的な反省点としては: