エムオーテックス株式会社が運営するテックブログです。

採用情報

CodiMDをAzureからAWSに移行した話

AWS 働き方 改善活動

CodiMDをAzureからAWSに移行した話

はじめに

こんにちは！ 今期アプリケーションチームに配属された、新入社員の古山、白石、園田です。

先日、社内で利用されているCodiMDというツールの運用環境を、AzureからAWSに移行する機会がありました。
移行するにあたって、調査・設計から移行完了までの流れを体験記としてご紹介します。

本記事では、若手社員が取り組んだ業務の一部を知ってもらい、エムオーテックスの雰囲気を少しでもお伝えできればと思います。

背景

エムオーテックスでは、開発においてCodiMDというツールを活用しています。
CodiMDとは、ブラウザ上でMarkdown形式のドキュメントを作成できるツールです。
リアルタイムで共同編集が可能であり、弊社では会議の議事録や技術文書の作成に使用しています。

LANSCOPE エンドポイントマネージャー クラウド版の開発業務では、主にAWSを利用しています。
しかし、社内ツールのCodiMDはAzure上で動作していたため、管理が属人化している状態でした。
そこで、管理の一元化を図るために、CodiMDをAWSへ移行するプロジェクトが立ち上がりました。

研修後、我々新入社員が初めて挑戦するプロジェクトとなったため、AWS環境でのCodiMDの構築やデータ移行を経験することで、LANSCOPE エンドポイントマネージャー クラウド版のクラウド基盤として使用しているAWSの理解を深め、スキルアップを目指しました。

プロジェクト概要

作業期間

このプロジェクトの作業期間は約2ヶ月でした。

チーム体制

プロジェクトチームは、1年目社員が3人、2年目の先輩方が3人、そして課長1人の計7人で構成されました。
1年目のメンバーが中心となって作業を進め、2年目の先輩方が全体の進捗管理とサポートを行いました。

調査・設計

既存構成

既存の構成では、AWSのALB（Application Load Balancer）でAzureサーバー内のnginxにリダイレクトし、nginxでCodiMDと別社内ツールへのリダイレクトを実現していました。
既存のドメインを使ったリンクを引き続き利用するためには、単純な移行ではなくリダイレクトを行うことが必須でした。

既存システムの構成図

リソース選定

移行にあたり、以下の構成図を考案しました。

考案した構成図

リソース選定において、ポイントはEC2インスタンスをプライベートサブネットに配置したことです。
プライベートサブネットに配置することで、EC2上で動作するDockerコンテナ内のCodiMDのアプリケーションとデータベースに対して外部アクセスを遮断し、セキュリティを強化しています。

しかし、このリソース選定によって1つの問題が起こりました。
それは、CloudFrontがプライベートサブネットに対して直接通信できないことです。
結果、CloudFrontの代わりにWAFやACM証明書を利用したセキュリティの向上が可能となるALBを使用する構成に変更しました。

Cloud FrontからALBに変更した構成図

なお、本記事を公開した現時点ではCloudFrontから直接プライベートサブネットにアクセスすることが可能となっています。

aws.amazon.com

また、画像保存用のストレージには、S3を採用しました。
S3は高い耐久性と可用性を誇り、データの安全な保存が保証されます。
しかし、S3への安全な通信を確保するためには、インターネットを経由せずにVPC内からデータ転送を行う必要があります。
そこで、VPC Endpointを採用することで安全かつ効率的なデータ転送を実現しました。

画像保存

調査を進めていく中で、CodiMD上に添付した画像がS3にうまく保存されない問題が発生しました。
リファレンスを確認したところ、以下のような表が記載されていました。

Environment Variable config.json Description
CMD_S3_ACCESS_KEY_ID accessKeyId AWS access key id.
CMD_S3_SECRET_ACCESS_KEY secretAccessKey AWS secret key

（引用元：https://hackmd.io/c/codimd-documentation/%2Fs%2Fcodimd-configuration#S3)

環境変数としてAWSのアクセスキーとシークレットアクセスキーを設定すれば画像が保存できると考えました。
そこで、AWS SSOユーザーの情報で試してみましたが、うまくいきませんでした。
次に、IAMユーザーのアクセスキーとシークレットアクセスキーを使用してみたところ、画像を保存することができました。

データ移行

データの移行については、移行元／移行先ともにPostgreSQLを使用していたため、pg_dumpコマンドを使ってバックアップファイルを作成し、そのファイルを新しいCodiMDのPostgreSQLに復元することでデータ移行を行うことにしました。

SSHを使ってデータを転送しようと試みたところ、転送先のCodiMDをデプロイしたEC2インスタンスがプライベートサブネットに存在していたため、転送に失敗しました。
そのため、同じVPC内のパブリックサブネットに踏み台用のEC2インスタンスを用意しました。
このようにすることで、以下のデータ移行図の②、③のように踏み台EC2インスタンスを経由し、プライベートサブネット内のEC2インスタンスにデータを転送することができました。

データ移行図
以下は①〜④の工程で用いたコマンドになります。

# ①バックアップファイル作成
pg_dump -U <postgres_username> <backup_table> > <backup_file>.sql

# ②バックアップファイル転送(踏み台EC2)
scp <backup_file>.sql <踏み台EC2のusername>@<踏み台EC2のパブリックIPアドレス>:<配置フォルダのパス>

# ③バックアップファイル転送(CodiMD-EC2)
scp <backup_file>.sql <CodiMD-EC2のusername>@<CodiMD-EC2のプライベートIPアドレス>:<配置フォルダのパス>

# ④バックアップファイルをPostgreSQLコンテナに転送
sudo docker cp <backup_file>.sql <データベースのコンテナ名>:<配置フォルダのパス>

ここまでで、バックアップファイルをPostgreSQLコンテナに転送することができました。
最後は⑤バックアップファイルから復元になりますが、GitからデプロイしたCodiMDのPostgreSQLコンテナにそのまま復元しようとしても失敗してしまいました。
これは、CodiMDのPostgreSQLの移行前と移行後のユーザー情報が異なっていたためです。
そのため、バックアップファイルから復元を行う前にユーザー作成をすることで、ユーザー情報の整合性を取る必要がありました。
以下のコマンド、クエリをもってこの問題を対処しました。

# PostgreSQLにログイン
psql -U <postgres_username> -d postgres

# PostgreSQLでのクエリ
# ユーザー作成
CREATE USER postgres WITH PASSWORD 'password';
# テーブルの初期化
DROP DATABASE <table_name>;
CREATE DATABASE <table_name>;

# ⑤バックアップファイルから復元
psql -U <postgres_username> -d <table_name> < <backup_file>.sql

以上をもって、既存のCodiMDからのデータ移行を完了させることができました。

検証

開発環境でCodiMDを構築し、データ移行も問題なく行えることを確認しました。
しかし、AWS内でのリダイレクトは行えているものの、Azureに向かっている通信のリダイレクトがうまくできていないことが発覚しました。

リダイレクト問題

プロジェクト始動当初はAzureVM上のnginxではなく、その前段にALBを配置することでリダイレクトを行う予定でした。

当初考案した構成図

しかし、いざリリースという段階でAzureVM上の社内ツールに正常にアクセスできないことが発覚しました。
この原因は既存の構成において、nginxでLet's Encryptを使って証明書を取得し、以下の図のようにRoute53からの通信を暗号していたためです。
そのため、間にALBを挟むことによって通信元が変わってしまい、AzureVMにアクセスできなくなりました。

移行問題点
ALBを使ったままこの問題を対応するためには、ALBとnginxの間にもう一度Route53を挟み、nginxで証明書を取り直すこととなります。
この構成は、開発工数とコストの面でデメリットが大きいと判断したため、ALBの使用を取りやめ、代わりに既存のnginxを使用してルーティングを行うようにしました。
現状構成では、ALBで担ってもらう予定のリダイレクト機構をnginxに残したまま、リダイレクト先をAWSの新たなRoute53に移しました。
この構成にすることで、追加リソースを増やすことなくAWS環境へのリダイレクトが可能となりました。

最終構成図

以上で、必要な開発が完了しました。

リリース

リリース前にリダイレクト問題に気づけたことで、大きなトラブルなくリリースを終えることができました。

所感

今回のCodiMDのAWS移行プロジェクトでは、新人3人をメインに作業を進めました。
このプロジェクトを通じて、開発本部にとって重要なツールの保守性を改善し、部全体に貢献できたことを嬉しく思います。
また、プロジェクトを通じて私たちはAWSに対する理解を深めることができました。
今後は、この移行プロジェクトで培った知識を活かし、より良い製品を提供していきたいと考えています。

おわりに

今回のプロジェクトでは、移行の目的である属人化の解消、そして我々新人のAWSに対する理解を深め、スキルアップすることができました。
最後までお読みいただき、ありがとうございました。