この記事はエムスリー Advent Calendar 2021 の24日目の記事です。
エムスリーエンジニアリングG コンシューマチームの松原(@ma2ge)です。 2021年4月にチーム異動をして、入社当時に所属していたチームにまた戻ってきました。 コンシューマチームでは AskDoctors に代表されるコンシューマ向けのプロダクト開発を日々行っていて自分もその一員として働いています。 また9月からは SRE *1 としての役割も持ち、インフラ面も学びつつ開発をしています。 本記事では今チームが注力しているクラウド移行について、自分が担当した部分について紹介したいと思います。
15年間続いているサービスのクラウド移行
こちらの記事でも紹介されているように、エムスリーではクラウド移行を推し進めており、コンシューマチームにおいてもこちらは同様です。
特に AskDoctors は15年もサービスが続いており、ほとんどのサービスがオンプレで構成されています。 しかし、オンプレでは OS のアップデート等を機動的に行うことが難しく、それがセキュリティリスクや、アプリの使っているフレームワーク等のアップデート、新しい機能追加への障壁にも繋がり、さまざまな点で事業運営に負の影響を与えている場面もよく目にするようになってきました。 そのため AskDoctors においてもクラウド移行は、事業推進にインパクトを与える課題の1つとして認識され、対処を進めている最中となります。 今回はその中で自分が担当した管理画面の移行について書きます。
移行にあたって気をつけたこと
移行対象となるのは AskDoctors を支えるサービス群にある管理画面アプリの1つです。
移行にあたってのゴールは AWS のシステム上で対象のアプリが動き、既存のオンプレシステムの依存から解放されることです。 クラウド移行の開発中も事業を進めるための開発は随時行われているため、そこにも気を配りつつ対応を進めました。 ゴールを目指す上で特に気をつけていた点を以下に記します。
移行後の構成について
持続的にサービスを提供していくためには、ある程度時流に乗った技術を取り入れていく必要があると考えています。 もし新しい技術に取り残されてしまうと、その新しい技術のメリットが事業に活かせず競争力が落ちてしまいます。 また現場で働いている方は古い技術を使い続けることで市場価値が落ちてしまいますし、新しくサービスを担当する方は古い技術(市場価値を生まないかもしれない)を学ばなければなりません。 次第に採用にも苦労するようになっていき、事業を維持するだけも精一杯のような状態となってしまいます。
現チームのインフラ部分に当てはめると、今取り入れるべきはすでに一般的になっているコンテナ技術を使ったサービス構成です。 実際チームでは、すでにクラウドに移行したアプリでもコンテナ技術を使いそのメリットを享受していたため、今回の移行でもその構成にならうことにしました。 ざっくりと説明するとアプリ部分を AWS Fargate にし、cron で実行されていたジョブを AWS Batch を使った構成としています。
上記背景もありすでにチームで作られていた terraform での構成管理や、GitLab CI を使ったイメージのビルド、デプロイの仕組みといった資産も存在していたため、構成を合わせることでそれら資産を活用でき、素早く移行の対応を進めることができました。ベース部分を作ってくれたチームメンバーに感謝しています。
※terraform の構成については、下記記事にあるものと近い構成となっています。
移行対象の把握
移行をスムーズに安全に進めるためには移行対象を把握することが大事です。
今回の管理画面は Rails で作られたアプリで、オンプレの DB へ繋ぎに行く他に、その他の内部システムとの連携や、一部の画面については外部の方からアクセスされる等の特徴がありました。またアクセス数はそれほどではないものの、アプリが落ちてしまうとその間サービスが提供できなくなるミッションクリティカルな側面も持ち合わせています。
そのため主に下記に注意して調査、対応すべき点の洗い出しを行いました。
- 内部システムへの接続
- 外部からの接続許可設定
- アプリの冗長構成
また Twelve-Factor App を参考に、コンテナ化するためのコード全体の再調査をし下記のような対応も行いました。
- ログの出力先を標準出力へ
- SIGTERM を受けて Graceful に停止するための設定
ただ先ほど書いたようにクラウド移行するまでは既存環境でも動かないと事業開発ができないため、これらを環境変数で切り替えられるような実装をし継続開発できる形としました。
余談ですがこの時全体を見直したことによって特定の assets ファイルが出力されない不具合にも対処できました。 過去の Rails アップグレード時に埋め込まれてしまった問題だったのですが、たまたまオンプレマシンに故障もなく過去に生成されていたファイルがあり見過ごされていたようです。 偶然ではありますが気がつけてよかったです。
上記観点で移行の障害となる点を早期に洗い出せていたため、ほとんどの部分をスムーズにリリースできました。 いずれも当たり前なところもあるかとは思うのですが、そういった点を着実に潰していくことが成功確度の高いリリースへと繋がります。
まとめ
移行によってアプリの使っているフレームワーク等のバージョンも上げやすくなり、サーバ管理からも解放され、より事業開発に集中できる環境となりました。 また移行によってこれから入られる方にとっては、コンテナを使った開発でスムーズに参画でき、 一方の今働いている方にとっても市場価値を落とさずに引き続き仕事ができる環境となったのではないかと思います。 しかし、まだまだオンプレ部分はあるため引き続きクラウド化に向けた対応をチームで進めていきます。
We are hiring!!
エムスリーではテクノロジーを活用して医療業界を変えるプロダクト作りに取り組んでいます。 エンジニア、プロダクトマネージャー、プロダクトデザイナーを絶賛募集中です。 ご興味があればぜひカジュアル面談をしましょう。
*1:こちらの記事 https://www.m3tech.blog/entry/m3infra-3-years-history で紹介されているチーム SRE としての役割です
