アプリケーションの入れ替え
最終更新日: 2020年7月7日
R8 | R9
W-MSA のメリットは "ドメインアプリケーション単位で入れ替えができること" です。ここでは app1 と app2 にそれぞれ変更が生じた、というストーリーで、入れ替えのルールを説明します。
入れ替え手順は次のようになります。
すでに実行中の（旧版の）ドメインアプリケーションが存在しているときに転送処理が行われると、旧アプリケーションを運用しながら、転送された（新版の）ドメインアプリケーションの準備を行います。つまり、入れ替え中は一時的に、2つの仮想サーバが存在します。(*1)
新版の準備が完了し、起動が成功したタイミングで、以降の利用者からのリクエストは新版に切り替わります。切り替わったあと、旧版は停止します。このような入れ替えを rolling update 方式と呼びます。
入れ替えによっては、旧版と新版でテーブル定義の変更が生じる場合があります。具体的にはテーブルの追加、更新、削除です。テーブルの更新には、列の追加や削除および型の変更も含まれます。これらはすべて自動で行われます。(*2)
[ご注意ください] 型の変更を行った場合、旧データがそのまま利用できるという保証はありません。例えば文字列型項目を数値型に変更したとき、元のデータが数字表記でなければエラーになります。このような場合、テーブルの定義までは自動で対応していますので、データ自体の修正はドメイン管理者が手動で行うようにしてください。通常はAWS管理者と連携し、データベースに直接、SQL命令を発行してデータを改変する作業になります。
ドメインアプリケーション入れ替え後のデータのインポートは次の点を考慮して行ってください。
モデルのインポート処理は、他のドメインアプリケーションに影響を及ぼす可能性があることを踏まえ、慎重に行ってください。
その通りです。
利用者は入れ替え作業があっても、アプリケーションを継続して利用できます。入れ替え処理の前後で強制的にログアウトされるということはありません。
また、入れ替え作業が開始される前に処理中のリクエストがあった場合、そのリクエスト終了のために300秒(5分)、待機します。（これは Load Balancer の標準値です。設定変更により、最大で3600秒(1時間)待機させることができます。(*3)
なお、入れ替えによってテーブル定義が変更される場合には影響が生じます。具体的には、次のようになります。
これらの機能はバックグラウンドで行われているため、AWSのロードバランサでは管理されません。ロードバランサはリクエストに対するレスポンスが終わっていない機能 - CSVダウンロードなど - は指定時間まで待機しますが、レスポンスをすぐに返し、バックグラウンドで処理が継続されるような機能は管理できないためです。そのため、これらの機能は入れ替えのタイミングで強制的に停止されます。
この問題への対応として、システム管理者は入れ替えの前に、これらの機能を使えないようにすることが求められます。
できます。管理処理メニューからメンテナンスモードに入ってください。ジョブスケジュール機能と組み合わせて、指定した時間にすべてのドメインアプリケーションをメンテナンスモードとすることもできます。
入れ替えされます。ただし入れ替え途中でもサービスは停止していないため、一時的に旧と新のアプリケーションが混在する期間が生じます。旧アプリケーションにログオンしていた利用者は、入れ替えがあったことを知ることはありません。すべてが入れ替わったあとで、旧アプリケーションは停止されます。
なお、入れ替えの前に AWS 管理者と連携し、事前にオートスケールを無効にすることもできます。各ドメインアプリケーションが最大でも1仮想サーバでしか動作していない、という最小構成にしたあとで入れ替えを行うと、作業時間はもっとも短くなります。入れ替え後、再びオートスケールを有効にしてください。
(準備中)
AWS管理者に連絡して、旧版が残っているかどうかを確認します。残っていた場合、こちらを手動で起動します。
データベースのバックアップから戻してください。すなわち、入れ替え作業の前にはデータベースのバックアップを行っておく必要があります。
すべてのドメインアプリケーションを入れ替えます。（準備中）
ローリングアップデート方式
手順
転送後の処理の流れ
テーブルの自動変更
重要
インポート
注意
よくある質問と回答
サービスを停止せずに入れ替えができる、ということですか？
入れ替えによって、すでにアプリケーションを利用している利用者に影響はありますか？
パターン
例
影響
モデル項目の変更がない。
自動計算式の変更や画面レイアウトの変更など。
影響はありません。利用者は処理を継続できます。
モデルまたはモデル項目の追加、削除、変更を伴う。
一覧表示、検索条件の変更も含む。(*4)新しいモデルを追加する。
新しいモデル項目を追加する。いずれかのドメインアプリケーションにログオンしている利用者は、入れ替えが終了したタイミングで、何らかのアクションを行うとメニュー画面に遷移します。（注 登録画面や更新画面を開いて入力していた値も無効になります。）ただし再ログオンする必要はありません。メニューに戻ったあと、再び業務を再開することができます。
入れ替えの前に実行されていたアップロード更新処理や、非同期ジョブはどうなりますか？
入れ替えの前に、現在ログオンしている利用者を強制的にログアウトさせることはできますか？
オートスケールと併用していたとき、複数のアプリケーションはすべて入れ替えされますか？
すべての入れ替えが完了してから、ある時間になったらサービスを再開させる、という運用はできますか？
入れ替え途中に AWS 側で予期しないエラーが生じた場合は、どうすればいいですか。
アプリケーションを旧版に戻すことはできましたが、データベースを元に戻すことはできますか？
共通モデルまたはシステムモデルが変更された場合