20 Feb 2017, 18:42

参加してきた、MSPJマイグレーションコンペ2017winter

先日、2017年2月18日に「MSPJマイグレーションコンペティション2017winter」に参加してきた。
MSPJマイグレーションコンペティション2017winterとは、
日本MSP協会コンペティショングループが主催する、 次代を担う若手運用技術者同士の交流・競争を通して日本のMSP事業者における運用技術の向上を目指したコンペティション

もう少し平たく言うと、MSP事業者の本当の業務に近い形でのコンペを通じて、スキルアップを図りましょうというものだ。
自分はMSPの人じゃないけど参加は全然できた。

connpass.com

競技ルール

今回の競技のお題は、
AWS上で動作しているレガシーなRedmineをAzure上に移行する」というものだ。

このコンペの特徴としては、実際にMSPでの業務に則し、お客さんから曖昧な要望を受けている部分や、
お客さん側にしかない権限については、お客さんと調整する必要があること。
例えば、環境の移行する際にはDNSの切り替えが必要だったのですが、DNSの設定権限は我々にはなくて、
Slackを利用して、DNS設定変更依頼や作業周知を出さなければいけなかった。
このあたりはとてもユニークなポイント。

お客さんからは移行について以下のような曖昧な要望をもらっていた。

<要望>
- 今の環境を新しい環境に完全移行して欲しいです。
- 実施した内容と結果については報告が欲しいです。
- システムを止めるときは利用者に告知が必要なので連絡が欲しいです。
- 昔から使っている古い環境なので、バージョンアップして欲しいです。
- できれば利用者に影響を出さないように切り替えたいです。
- できればサーバに関する資料があるとありがたいです。
- できれば今はまったくバックアップを取っていないのでバックアップを取れるようにしたいです
- できれば今後は利用者が増えるのでシステムを冗長化したいです。
- できれば新しいインフラエンジニアに引継ぎするために必要な情報がまとまっていると嬉しいです。

<担当者のコメント>
- 前任のインフラエンジニアが辞めちゃったのでこのシステムもう分かる人がいなくって。
- 結構前から使っているので環境も古くなっているみたいで、OSのサポートがもうすぐ切れるって話を聞いたものですから、セキュリティとか色々心配で何とかしたいんです。
- みんなこのシステムを結構便利に使っていてくれているようだから、システムを切り替えるときは連絡しないとなぁ。
- そうそう、近々新しいインフラエンジニアが入社予定だから、その方に引き継げるようになっていると嬉しいですね。 

ちなみにチームについては、当日の参加者で適当に3人チームを作って行った。
一緒の参加者が同じチームにならないように調整された。

構成把握

開始後、まずやったことが環境・構成の把握。
ざっと下記のような感じ。ログインしてすぐに、pstree みて大体の構成を把握した。

  • インフラ: AWS(EC2)
  • OS: CentOS5.2
  • Webサーバ: Apache2.0 + Passenger
  • DB: MySQL5.1
  • Ruby: 1.9
  • Redmine: 2.3
  • DNS; Route53で管理。権限はお客さんのみ
  • サーバ構成: サーバ1台のシングル構成

移行作戦

細かなバージョンはおいておいて、最終的に目指す構成は下記のようにした。
これに至った考え方とかは下に書く。

冗長化の観点

まず、Webサーバをロードバランサを利用して負荷分散と冗長性を確保した。
Azureではロードバランサーのフルマネージドサービスがあるので、
ロードバランサー自体の冗長化については考える必要がなかった。

Azure Load Balancer の概要 | Microsoft Docs

次にデータベースだが、当初ロードバランサと同様にマネージドサービスがあればそちらで対応しようと検討していた。
SQL Databaseというサービスがあるのだが、「Microsoft SQL Server エンジン」のみの対応とのことで、
今回のRedmine移行には適切ではなかった。

SQL Database とは SQL Database の概要 | Microsoft Docs

ということで、MySQLレプリケーションを使ったデータベースを作ることにしたのだが、
自前で作っている余裕はとてもなかったので、マーケットプレイスから
MySQL with replicationというイメージを見つけて対応することとした。

Microsoft Azure Marketplace

最後に、Redmineでは添付ファイルのアップロードなどをすることがある。
ロードバランサーで負荷分散環境においては、添付ファイルを共有する必要がある。
手っ取り早くRsyncでの同期をする方向にした。

バージョン関連

移行先の各種バージョンは下記とした。

  • OS: CentOS7.2
  • Webサーバ: Nginx
  • DB: MySQL5.7
  • Ruby: 2.2(アプリケーション実行はthin)
  • Redmine: 2.6

はじめRuby2.4で検証していたのだが、
さすがにRails3はRuby2.4では動かずRuby2.2まで下げた。

Webサーバ、アプリケーションサーバ関連

移行元の環境では、RedmineApache+Passengerで動作していた。
余談になるが、Passengerはmod_railsなんて呼ばれることもあって、いわゆるmod_php, mod_perlと同じ方式での動作方法。

昔にPassengerインストールでハマった記憶もあるし、特にPassengerである必要性はなかったので、
馴染みのあるNginx+Thinの構成で動かすこととした。
※Thin部分はpumaでもunicornでもお好きなものをどうぞ。

この構成はWebサーバとアプリケーションサーバを分離するアーキテクチャ
Thin単体でも動作させることが可能。Nginxはリバースプロキシや静的ファイルの配信に特化し、
アプリケーションの実行はThin側に任せる。

正直どちらでもかまわないのだが、Passengerを利用する場合、
アプリケーションとインフラ(Apache部分)が密な関係になってしまうのが煩わしいと個人的に思う。
まあケースバイケースでしょうが。

※あと最近Apache触ってなさすぎて忘れた…

移行作業

作戦が決まったところで、さっそく移行作業なのだが、
いきなり完成形に持っていくことは難しいと考えいくつかのステップに分けて移行作業を進めた。

Step1:まずはAzure環境へ

Step2:冗長化とか

Step3:最後の仕上げ

Azureのここがよくわからなかった

限られた時間内で、ほぼ初めてAzureをまともに使ったわけだが、
いくつか概念の理解や操作方法がわかりづらいなと感じた。
(IsuconでもAzure触ったが、あれは本当にサーバ起動するだけなので…)

ネットワーク概念

Virtual Private Networkの概念がとてもわかりづらかった印象。
買ったリソースをどうやって、指定のネットワークにデプロイするのかなど。
慣れの問題も大きいとは思うが、当日はほんとにわからなかった。

サーバのイメージ作成

すごい初歩的なことだが、構築したサーバのイメージを作成して、複製することがとても難しかった。
メンバーがいろいろ躓いていたので、最終的に普通にもう1台構築するという強行手段を取った。
この点は、クラウドに携わるものとして仕様確認しておきたい。

仕事で使っているクラウドAWS的なため、
AWSの考え方にFitするものはすぐに理解できたが、Azureはまた独特の概念が多い印象。
これだけAWSが使われている現代に、「AWS的」であることは価値がある!??

結果、懇親会とか

んー。結果は優勝・準優勝ではなかったんですが、
きっとテストをちゃんとしないで移行したので、きっと触るとなにか抜け漏れがあったのでしょう(笑)
また来年あれば参加したいなと思える楽しいコンテストだったことは間違いない。
ISUCONに続き悔しい結果。

参加者の中には、MSP業界の方がもちろんたくさんいた。
懇親会でいろいろ話をしたけどざっくりこんな課題を抱えている人が多かった。

アプリが悪い問題

MSPなのでお客さんのシステムの運用を請け負います。
その業務の中には障害対応や監視設定、デプロイとか様々あるわけですが、
アプリの作りにより、監視設定できないことや自動化できないことが多数あるそうです。
お客さんのせいにしてはいけないのだけど、その点が一番しんどそうだった。

自動化・コード化

MSPの方々も本当は監視やデプロイなどの自動化するコードやツールを作ることに力を入れたいけど、
単純な手順書作業や日々の障害対応に追われてなかなかできないとか。
そもそも普段コードを書く仕事ではないので、そのメンテするチーム体制が取れないという問題も。
(それは前の仕事でもよく聞いた話だなぁ~)

オンプレ

まだまだオンプレ環境の運用も多く、
ハードウェア交換やハードウェアによる障害には悩まされているとのこと。
聞いてる話だと、あえてオンプレにしているというよりはレガシーで残っているのが多いっぽい。

夜勤

夜勤の週は、5日間夜勤をする。そういう運用らしいです。
前の仕事では身近にネットワークの運用部隊がいたので夜勤事情はよく聞いていますが、 まったく考え方が違くてびっくり。
でも意外と、週ごとに別れている方が辛くないらしいよ?

最後に

一緒に戦ってくれたチームメンバーありがとうございました。

去年のお題はVPSからクラウドへの移行だったらしいですが、今回はクラウドからクラウドへの移行。
このあたり、そういう時代のフェーズに入ってきているということなんでしょうか。
きっとそういうことでしょう。

特定のクラウド独自の機能を使っていなければ、移行自体は簡単で、
それよりももともとのレガシーシステムをバージョンアップするほうがしんどい印象。
クラウドロックインとどう向き合っていくか、考えなければ。

このエントリーをはてなブックマークに追加