もーすけです。先日、2017年2月18日に「MSPJマイグレーションコンペティション 2017 Winter」に参加してきました。 MSPJマイグレーションコンペティション2017winterとは、日本MSP協会コンペティショングループが主催する、 次代を担う若手運用技術者同士の交流・競争を通して日本のMSP事業者における運用技術の向上を目指したコンペティションです。
こういったコンペティションだとISUCONが有名かと思います。
MSPJが開催するマイグレーションコンペティションもMSP事業者の「本当の業務に近い形でのコンペ」を通じた出題となっており、おもしろいコンペです。まだ認知度もあまりないらしく？参加人数は少ないが優勝するとお金はたくさんもらえるのでぜひ参加して見てほしいです。
競技ルール
今回の競技のお題は、**「AWS上で動作しているレガシーなRedmineをAzure上に移行する」**というものでした。 （追記: その後2018,2019年も開催されていますがルールは概ねこのような形です。）
このコンペの特徴は、実際にMSPでの業務に則して、お客さんから曖昧な要望を受けている点や、 お客さん側しかできない作業については、お客さんと調整して実施してもらう必要がある点などです。 例えば、既存の環境からクラウドの新しい環境へ移行する際にはDNSの切り替えが必要だったのですが、DNSの設定権限は我々にはなかったため、Slackを利用してDNS設定変更依頼を出さなければいけませんでした。 この点はコンペとして非常にユニークなポイントです。
仮想のお客さんからはシステム移行について以下のような曖昧な要望をもらっていました。 つまりこれが、コンペのレギュレーションです。
<要望>
- 今の環境を新しい環境に完全移行して欲しいです。
- 実施した内容と結果については報告が欲しいです。
- システムを止めるときは利用者に告知が必要なので連絡が欲しいです。
- 昔から使っている古い環境なので、バージョンアップして欲しいです。
- できれば利用者に影響を出さないように切り替えたいです。
- できればサーバに関する資料があるとありがたいです。
- できれば今はまったくバックアップを取っていないのでバックアップを取れるようにしたいです
- できれば今後は利用者が増えるのでシステムを冗長化したいです。
- できれば新しいインフラエンジニアに引継ぎするために必要な情報がまとまっていると嬉しいです。
<担当者のコメント>
- 前任のインフラエンジニアが辞めちゃったのでこのシステムもう分かる人がいなくって。
- 結構前から使っているので環境も古くなっているみたいで、OSのサポートがもうすぐ切れるって話を聞いたものですから、セキュリティとか色々心配で何とかしたいんです。
- みんなこのシステムを結構便利に使っていてくれているようだから、システムを切り替えるときは連絡しないとなぁ。
- そうそう、近々新しいインフラエンジニアが入社予定だから、その方に引き継げるようになっていると嬉しいですね。
どのように勝敗を決めるかというと、以下のような点を総合的に判断しているようです。
- 時間内にシステム移行ができたか
- 移行先のシステムは要望通りに仕上がっているか
- 移行時に、ユーザへの周知などの調整ができていたか
- 移行時に、利用者の影響が少なかったかどうか
チーム編成は、ISUCONと異なり、当日の参加者で適当に3人チームを作って行いました。 勝ちに行くためにチームを組む形式ではないです。仲間内が同じチームにならないように調整されました。
構成把握
開始後、まず必要なことが現状の環境・構成の把握です。
現状の構成についての情報は開示されていなかったため、自ら調べていく必要があります。
pstreeやバージョンを確認するコマンドなどを使ってすばやく構成を把握できるようにしておくとよいです。
実際には、下記のような構成で動いていました。
- インフラ: AWS(EC2)
- OS: CentOS5.2
- Webサーバ: Apache2.0 + Passenger
- DB: MySQL5.1
- Ruby: 1.9
- Redmine: 2.3
- DNS; Route53で管理。権限はお客さんのみ
- サーバ構成: サーバ1台のシングル構成
移行作戦
次にやるべきことは、現状の構成を踏まえ、最終的に目指す構成をチームの中で相談することです。 このコンペでは、パフォーマンスを競う戦いではないので、一般的なクラウドでの冗長化のとれたシステム構成にすることが一番重要です。 移行先のクラウドのことについて知識があるほうがより速く適切なアーキテクチャが組めるでしょう。 クラウドのマイグレーションコンペでもあるので、移行先のクラウドについては予習しておくとよいです。
使用するミドルウェアなども、慣れているものを使うことが一番よいでしょう。例えば、自分の場合、WebサーバはApacheよりもNginxのほうが設定に慣れていたのでNginxを採用するなど、慣れているものを選びました。
冗長化の観点
Webサーバをロードバランサを利用して負荷分散と冗長性を確保しました。 Azureではロードバランサーのフルマネージドサービスがあるので、迷わずマネージドサービスを採用しました。 ロードバランサー自体の冗長化については考える必要がなかったです。
Azure Load Balancer の概要 | Microsoft Docs
次にデータベースですが、当初ロードバランサと同様にマネージドサービスがあればそちらで対応しようと検討していました。 当時のAzureにはSQL Databaseというサービスがありましたが、「Microsoft SQL Server エンジン」のみの対応とのことで、今回のRedmine移行には適切ではなかったため別の方法を考える必要がありました。
MySQLレプリケーションを使ったデータベースを作ることにしたのですが、自前で作っている余裕はとてもなかったので、マーケットプレイスからMySQL with replicationというイメージを見つけて対応することとしました。
最後に、Redmineでは添付ファイルのアップロードなどをすることがあります。 Wordpressでも同じですが、添付ファイルはデフォルトではサーバのローカルに保存されるため、ロードバランサを使用した負荷分散環境においては、添付ファイルを共有する必要があります。 方法はいくつかありますが、手っ取り早く実装できるRsyncでの同期を採用しました。
OS、ミドルウェア関連
移行先では最終的に下記のようなOS、ミドルウェア、バージョンを使用することにしました。 選定で重要視したのは速く実装できるかどうかです。前にも書きましたが、システムパフォーマンスは重要ではないので自分たちが慣れている実装を選ぶことがこのコンペにおいては重要です。実際の業務ではもちろんもっと真面目に選定しなければいけません。
- OS: CentOS7.2
- Webサーバ: Nginx
- DB: MySQL5.7
- Ruby: 2.2(アプリケーション実行はthin)
- Redmine: 2.6
移行作業
作戦が決まったあとは、さっそく移行作業にはいるわけですが、いきなり完成形に持っていくことは難しいと考え、いくつかのステップに分けて移行作業を進めることにした。
Step1：まずはAzure環境へ
まずは、Azure環境へできるだけシンプルな形でもっていこうと考えました。 チームがAzureになれていなかったこともあります。シンプルなアプリケーションとデータベースだけ分けてAzureへの移行を行いました。
Step2：冗長化とか
ロードバランサを挟んだり、ネットワーク周りの設定をするのをこの段階で行いました。
Step3：最後の仕上げ
最終ステップとして、データの移行だったり、バックアップなどの非機能要件をまとめていきました。
結果
結果は優勝・準優勝ではなかったんです。優勝と準優勝以外の順位は特にありません。 Azureの操作に手間どっていたのもあり、移行後のシステムのテストをきちんとできませんでした。おそらく、なにか抜け漏れがあったのでしょう。 実際の業務に近い要件のあるマイグレーションコンペということで、非常に楽しいコンテストでした。 勝ちたい人は、しっかりクラウドに慣れておくことが重要ですね。
懇親会
参加者の中は、MSP業界の方がもちろんたくさんいました。 MSPの方々とあまり接点がなかったので、懇親会でいろいろ話をしました。 現場での悩みはつきないようです。 悩みばかり書くと、MSPつらいと思ってしまうかもしれませんが、これをどう乗り越えるかがやはりビジネスとしての要でありやりがいのある部分とも言えます。
アプリが悪い問題
MSPなのでお客さんのシステムの運用を請け負います。 その業務の中には障害対応や監視設定、デプロイとか様々あるわけですが、 アプリの作りにより、監視設定できないことや自動化できないことが多数あるそうです。 お客さんのせいにしてはいけないのだけど、その点が苦労するポイントというそうです。 MSPも単なる運用代行ではなく、システムのリファクタリングの領域にまで踏み込んでいかないとビジネスとして難しそうです。
自動化・コード化
MSPのビジネスモデルでは監視やデプロイなどの自動化を徹底することが非常に重要です。
自動化やツール開発に力を入れたいけど、現実には単純な手順書作業や日々の障害対応に追われてなかなかできない悩みがあるそうです。
そもそも普段コードを書く仕事ではないので、そのメンテするチーム体制が取れないという問題もあるようです。
また、オンプレ環境の運用も多く、ハードウェア交換やハードウェアによる手作業はどうしてもつきまとう問題といいます。
夜勤
会社によるそうですが、夜勤の週と日勤の週で別れていて働くそうです。夜勤の週では5日間夜勤をする、そういうことです。 意外と、週ごとに別れている方が身体が慣れてくるので、肉体的な負担は少ないそうです。
最後に
一緒に戦ってくれたチームメンバーありがとうございました。
残念な結果ではありましたが、非常に有意義な一日を過ごせたことは間違いなしです。
これから参加していく人の参考になればと思います。
