GROWI（社内Wiki）をAzureからAWSに移行してみた

はじめに

こんにちは、アプリケーションチームの野地・奥田・山田です。
テックブログならびに本記事を閲覧いただきありがとうございます。

先日、社内Wikiとして利用しているGROWIを、Azure環境からAWS環境に移行する機会がありました。
めったにできない経験だったので、移行が完了するまでの流れを体験記としてご紹介します。

growi.org

はじめに
背景
プロジェクト概要
- 作業期間
- チーム体制
調査
リリース
所感
おわりに

背景

エムオーテックスでは開発に関する知識をまとめる場としてGROWIを活用しています。
その中には開発プロセスやコーディング規約等の大事な決まり事も含まれており、GROWIを継続的に運用することは開発に携わる部署の業務効率化に欠かせません。

そんなGROWIですが、社内では以下の課題がありました。

一部の人で運用されていて負荷や知見の偏りが生まれている
かつてはAzureが社内で活用されていたが、現在はAWSがメインである

そこで、これら課題の解決にむけた移行計画が始動しました。

プロジェクト概要

作業期間

他の業務を行いながらも、約3ヶ月という期間でプロジェクトを進め、リリースに成功しました。

チーム体制

今回、AWSの勉強とサーバー移行という貴重な体験も兼ねて、若手社員主体で移行作業を実施しました。

設計・開発担当：1年目3人
プロジェクト管理：2年目3人
管理監督：課長

調査

設計

プロジェクト開始時のAWS環境移行における構成イメージはこちらです。

この構成に対して、

EC2のメンテナンスの手間を削減したい
稼働に必要なサービスが1つのEC2に集約されていることが不安

という声もあったため、使用するリソースの選択も含め、改めて設計を行いました。

設計では、GROWIの現在のランニングコストを超えないことをマストにしてリソースを決定しました。
はじめはECS on EC2に着目しましたが、細かな管理が不要であるECS Fargateも視野に入れて調査しました。
しかし実際に調査してみると、FargateではGROWIに必要なDockerコンテナをうまく繋げることができませんでした。
原因もすぐにはわからなかったため、今回は工数の都合上断念しました。

これらの調査を経てまとまった構成イメージは、以下のEC2パターンとECS on EC2パターンの2つです。

自分たちが把握していないベストプラクティスやリソースの使い方が多く、不安が残っていたところに「AWS様とミーティングで相談してみてはどうか」と先輩からアドバイスをいただきました。
その提案に驚きましたが、早速AWS様にご意見を伺うことにしました。
事前に質問事項をまとめ、緊張して臨んだミーティングでしたが、技術的知見に基づく丁寧でわかりやすい回答をいただくことができました。

こうした相談や技術的な制限も鑑みて、障害時の復旧の簡単さでEC2に軍配があがると考えたため、最終的にはEC2パターンの構成に決めました。

検証

検証は次の3つを並行して行いました。

固まった設計をもとに、AWS上で実際にGROWIを構築
データ移行の手順を確認
AWS WAFを使用したセキュリティ設計や、AWS Backupを使用した障害時の復旧手順を確認

セキュリティ設計ではSRE（Site Reliability Engineering）チームに協力してもらいながら、LANSCOPE製品と同じ設計ルールに可能な限り沿えるよう進めました。
その中で、継続的に運用していくものの開発とはどういうことか、バックアップの必要性などの意識するべきことを身につけられました。

リダイレクトの実装

GROWIが稼働していたAzure仮想サーバー上ではそれ以外のサービスも稼働しており、全てのサービスは同じドメインに属していました。

移行前イメージ

URL	アクセス先サーバ
`https://motex-dev-hogehoge/` `https://motex-dev-hogehoge/serviceA` `https://motex-dev-hogehoge/serviceB`	Azure

今回はGROWIのみをAWS環境へ移行するため、AWS上で新しいドメインを発行する必要がありました。
しかし、このままではGROWIのURLが変わり、既存の資料に存在するGROWIのリンクが切れてしまいます。

移行後イメージ

URL	アクセス先サーバ
`https://motex-dev-hogehoge/`	AWS
`https://motex-dev-hogehoge/serviceA` `https://motex-dev-hogehoge/serviceB`	Azure

リンク切れを回避するために、リダイレクトを実装しました。

このリダイレクトを含めて、最終的にとった構成がこちらです。

リリース

そして迎えたリリース当日。
作業をしていたところ、リダイレクトが正常に動作しないという課題が発生しました。
すぐに原因の調査を行いましたが、残念ながら当日中の解決には至りませんでした。
当日は「課題の原因はリハーサル時に完全に再現できていなかったAzure環境側にある」と想定して調査していたのですが、よく考えてみると「EC2を再起動する必要がある」と気づき、翌営業日に実施したところリダイレクト動作が正常に確認されました。

リリース当日にアクシデントもあり、肝を冷やしましたが、リダイレクトの実装を含めたGROWIのサーバー移行をなんとか無事に終えることができました！
また、GROWIのバージョンアップデートも併せて行い、最新機能で運用を楽にしつつ、脆弱性の対処もできました。実際に、バージョンアップで対応可能になった機能の利用者から「対応してくれて助かる」と声をいただけました。

所感

今回「インフラを1から設計するサーバー移行」という滅多にないプロジェクトを、入社1年目にして完遂することができました。
移行完了に至るまでの過程で、AWSの基礎的な知識から始まりネットワーク設計の知識も実践で養うことができ、非常に良い経験になりました。
特にリリース時のアクシデントからは、リハーサルや検証でなるべく本番と差異をなくして実施する重要性を学びました。今後の業務に活かしていきます！

また、リダイレクトの実装に伴い、想定していたランニングコストから追加で約5,000円/月ほどかかってしまいました。
コスト面については今後の運用課題としたいと思います。

研修を終えたばかりの新入社員3人がタスクを遂行できるか不安を感じることもありましたが、3ヶ月という期間で達成できてよかったです。
ご協力いただいた皆さん、ありがとうございました。

※ 今回のプロジェクトで、これだけ多くのリソースやサービスに触れました