アプリケーションの入れ替え最終更新日: 2020年7月7日

ローリングアップデート方式

W-MSA のメリットは "ドメインアプリケーション単位で入れ替えができること" です。ここでは app1 と app2 にそれぞれ変更が生じた、というストーリーで、入れ替えのルールを説明します。

手順

入れ替え手順は次のようになります。

  1. [AWS管理者] 入れ替える前の状態で、データベースのバックアップを取得します。
  2. [ドメイン管理者] 入れ替え対象のドメインアプリケーションをフルビルドします。
  3. [ドメイン管理者] Designer から転送します。

転送後の処理の流れ

すでに実行中の(旧版の)ドメインアプリケーションが存在しているときに転送処理が行われると、旧アプリケーションを運用しながら、転送された(新版の)ドメインアプリケーションの準備を行います。つまり、入れ替え中は一時的に、2つの仮想サーバが存在します。(*1)

新版の準備が完了し、起動が成功したタイミングで、以降の利用者からのリクエストは新版に切り替わります。切り替わったあと、旧版は停止します。このような入れ替えを rolling update 方式と呼びます。

1. AWSの課金の対象になります。

テーブルの自動変更

入れ替えによっては、旧版と新版でテーブル定義の変更が生じる場合があります。具体的にはテーブルの追加、更新、削除です。テーブルの更新には、列の追加や削除および型の変更も含まれます。これらはすべて自動で行われます。(*2)

2. スキーママイグレーション機能と呼びます。[詳細...]

重要

[ご注意ください] 型の変更を行った場合、旧データがそのまま利用できるという保証はありません。例えば文字列型項目を数値型に変更したとき、元のデータが数字表記でなければエラーになります。このような場合、テーブルの定義までは自動で対応していますので、データ自体の修正はドメイン管理者が手動で行うようにしてください。通常はAWS管理者と連携し、データベースに直接、SQL命令を発行してデータを改変する作業になります。

インポート

ドメインアプリケーション入れ替え後のデータのインポートは次の点を考慮して行ってください。

  • このドメインアプリケーションに所属するモデルは、必要に応じてインポートしてよい。選択肢モデルを追加した場合などがある。
  • 別のドメインアプリケーションに所属するモデルはインポートしないように注意する。
  • 自ドメインを含む、他のドメインにも所属しているモデルのインポート処理は、その他のドメインアプリケーション管理者と調整の上、必要に応じてインポートする。
  • 共通ドメイン、システムドメインについては専用のデータ管理者を決め、その管理者の判断で適切にインポートする。[データ管理者とは]

注意

モデルのインポート処理は、他のドメインアプリケーションに影響を及ぼす可能性があることを踏まえ、慎重に行ってください。

よくある質問と回答

サービスを停止せずに入れ替えができる、ということですか?

その通りです。

入れ替えによって、すでにアプリケーションを利用している利用者に影響はありますか?

利用者は入れ替え作業があっても、アプリケーションを継続して利用できます。入れ替え処理の前後で強制的にログアウトされるということはありません。

また、入れ替え作業が開始される前に処理中のリクエストがあった場合、そのリクエスト終了のために300秒(5分)、待機します。(これは Load Balancer の標準値です。設定変更により、最大で3600秒(1時間)待機させることができます。(*3)

3. 例えばCSVダウンロード処理や、一括処理が終了するまで、を想定して待機時間を決めます。ただしリクエストが終了するまで待つということではありません。入れ替えが始まると、それまでに完了できなかった(長い)処理は強制終了となります。

なお、入れ替えによってテーブル定義が変更される場合には影響が生じます。具体的には、次のようになります。

パターン 影響
モデル項目の変更がない。 自動計算式の変更や画面レイアウトの変更など。 影響はありません。利用者は処理を継続できます。
モデルまたはモデル項目の追加、削除、変更を伴う。
一覧表示、検索条件の変更も含む。(*4)
新しいモデルを追加する。
新しいモデル項目を追加する。
いずれかのドメインアプリケーションにログオンしている利用者は、入れ替えが終了したタイミングで、何らかのアクションを行うとメニュー画面に遷移します。(注 登録画面や更新画面を開いて入力していた値も無効になります。)ただし再ログオンする必要はありません。メニューに戻ったあと、再び業務を再開することができます。
4. 生成されるJavaソースコードの、modelサブパッケージの変更に該当します。

入れ替えの前に実行されていたアップロード更新処理や、非同期ジョブはどうなりますか?

これらの機能はバックグラウンドで行われているため、AWSのロードバランサでは管理されません。ロードバランサはリクエストに対するレスポンスが終わっていない機能 - CSVダウンロードなど - は指定時間まで待機しますが、レスポンスをすぐに返し、バックグラウンドで処理が継続されるような機能は管理できないためです。そのため、これらの機能は入れ替えのタイミングで強制的に停止されます。

この問題への対応として、システム管理者は入れ替えの前に、これらの機能を使えないようにすることが求められます。

入れ替えの前に、現在ログオンしている利用者を強制的にログアウトさせることはできますか?

できます。管理処理メニューからメンテナンスモードに入ってください。ジョブスケジュール機能と組み合わせて、指定した時間にすべてのドメインアプリケーションをメンテナンスモードとすることもできます。

オートスケールと併用していたとき、複数のアプリケーションはすべて入れ替えされますか?

入れ替えされます。ただし入れ替え途中でもサービスは停止していないため、一時的に旧と新のアプリケーションが混在する期間が生じます。旧アプリケーションにログオンしていた利用者は、入れ替えがあったことを知ることはありません。すべてが入れ替わったあとで、旧アプリケーションは停止されます。

なお、入れ替えの前に AWS 管理者と連携し、事前にオートスケールを無効にすることもできます。各ドメインアプリケーションが最大でも1仮想サーバでしか動作していない、という最小構成にしたあとで入れ替えを行うと、作業時間はもっとも短くなります。入れ替え後、再びオートスケールを有効にしてください。

すべての入れ替えが完了してから、ある時間になったらサービスを再開させる、という運用はできますか?

(準備中)

入れ替え途中に AWS 側で予期しないエラーが生じた場合は、どうすればいいですか。

AWS管理者に連絡して、旧版が残っているかどうかを確認します。残っていた場合、こちらを手動で起動します。

アプリケーションを旧版に戻すことはできましたが、データベースを元に戻すことはできますか?

データベースのバックアップから戻してください。すなわち、入れ替え作業の前にはデータベースのバックアップを行っておく必要があります。

共通モデルまたはシステムモデルが変更された場合

すべてのドメインアプリケーションを入れ替えます。(準備中)