ROBOT PAYMENT TECH-BLOG

株式会社ROBOT PAYMENTのテックブログです

長年運用しているWebサービスの可用性をアップさせた話

どうもこんにちは！ サブスクペイのシステム基盤チームの yoponpon です。 システム基盤チームではサービスの価値向上、チームの生産性向上に向けた働きかけを行っております。 今回はシステム基盤チームで推めている取り組みの一部を紹介できればと思います。

前置き

サブスクペイは基本的にAWS上に構築しており、かれこれ20年ほど24/365で稼働しているシステムです。 都度リプレイスや、システム移行をしつつここまでやってきているのですが、まだまだ古い構成になっている箇所が残っています。 今回はその一部で1台のWebサーバ構成、メンテナンスにはサービスの停止が必要な箇所を無停止でメンテナンス等できるようにした対応について説明します。

構成について

該当箇所のざっくり構成は以下図の通りとなります。 ※大まかな図なのでいくつかの要素は省いています。

  • WebサーバはActive/Standby構成となっていて、障害発生時にダウンタイムありで切り替わりが発生します。
  • Webサーバは状態を持っている（HTTPセッション、一時ファイル等）ので障害発生時にはデータの移行が必要です。
  • 通知サーバは一台構成となっており、障害発生時はサービスの停止に繋がります。
  • Webサーバ、通知サーバ内ではMicrosoft IISのプロセスが動作しています。
  • アプリは .net framework のWeb Formsで動作しています。

起きること

この構成でのシステム稼働上の問題は赤枠箇所で障害が発生した場合にもれなくサービス停止が発生する点です。 障害発生時は一時ファイル、HTTPセッションの消失が懸念されます。 また、メンテナンスを行うのにサービスの停止が必要になります。

実施したこと① - HTTPセッションと一時的なファイルの退避

まずはWebサービス/通知サービスの冗長化をしていきたいところですが、Webサービスがファイル/HTTPセッションなどの状態を持っているため、サーバ障害発生時にそれらを消失してしまう可能性があります。また、Active/Standbyの切り替え時にデータの移行が必要になったり運用上の手間も発生します。

ということでまずはサーバから状態を切り離す作業を行っていきます。

HTTPセッションについて

HTTPセッションの移行先は検討した結果 Elasticache (Redis) となりました。 以下図の通り、Webアプリのプロセス内に持っていたHTTPセッションをElasticache(Redis)へ持たせるように変更しました。

Webアプリは .net framework でできているためHTTPセッションの設定は比較的簡単に行うことができます。 Web.Configを編集する形となるのですが以下を参考にするとわかりやすいです。

https://learn.microsoft.com/ja-jp/azure/azure-cache-for-redis/cache-aspnet-session-state-provider

一時的なファイルについて

当Webアプリは一部で一時的なファイルを保持する仕組みがあり、それらもWebサーバから切り離し、別管理とします。 当Webアプリはコードが古くファイル参照/書き込みの箇所が多くあり、それらをすべて改修をすると影響が大きそうでした。 今回の目的は障害ポイントの解決が最優先であるためアプリの大幅な改修を行わなくても済む技術を選定した結果、Amazon FSx for Windowsを選択しました。 Amazon FSx for WindowsはWindows上からネットワークドライブとしてマウントできます。そのためアプリ上からのファイル参照、書き込み処理の宛先だけ変えれば良い形となり、アプリケーションの改修は最低限で済みます。

実施したこと② - 通知サーバの増強とロードバランサーの追加

通知サービスは1台の構成であるため、可用性を考慮して2台の構成とします。 通知サービスは状態（HTTPセッション、一時ファイル）を持っていないためアプリの改修を行わずに増強します。

  • Webサービスと通知サービスの間にALBを追加した。
  • 通知サーバを1台増やした。

最終的な構成についてと変わったこと

上記を複数回のリリースを通して実施して最終的に以下の構成となりました。 Webサービス、通知サービスは冗長化されメンテナンスの実施がサービスの停止なしで行えて、障害発生時もActiveな方へリクエストが流れるようになりました。サーバの増強はいくらでも行えるようになったので負荷に対しても強くなりました。

今後に付いて

といったような感じで、古いシステムの構成をちょっとずつ新しくしたり、問題を仕組みで解決していっているのが私達のチームです！ 今後は古いアプリのリプレイスやECSなどの導入、オートスケーリングなどやっていけたらなと思っております！ それではまた！！

We are hiring!!

ROBOT PAYMENTでは一緒に働く仲間を募集しています！！ 「古いものを新しく」「問題を仕組みで解決」「できる限り運用業務を楽に」これらにピンときた方はぜひ一緒に働きましょう！！ https://www.robotpayment.co.jp/recruit/engineer-recruitment/