サイト内検索
サイト内検索を閉じる

AWSのマルチリージョン構成で迅速なDR切替を可能にする仕組みの実現

TISでは、金融系をはじめとする高可用なシステムの実現を追求する中で、高い可用性とスループットを発揮するソフトウェアスタック『Lerna』を開発しております。今回、この『Lerna』をアマゾン ウェブ サービス(AWS)上に構築することで、高可用性を実現いたしました。本記事では「高可用性を実現するために求められる迅速な災対環境への切替をどのように実現したか」について解説していきます。

リージョン切替判断の前提

今回構築するシステムの要件として99.99%の可用性を実現する必要がございました。その高可用性を実現するために、東京被災時に加えてAWSの東京リージョン全体で障害が発生した場合や、業務処理で利用しているAWSサービスで東京リージョン全体の障害が発生した場合など複数のケースで、大阪リージョンに準備している災対環境へスピーディに切替を実施し、業務を継続することが求められます。

リージョン切替のフロー

今回のリージョン切替では東京リージョンでの障害発生後「①切替処理」を行い、大阪リージョンでのサービス提供を開始します。その後、東京リージョンが復旧次第東阪両環境において「②切戻準備」を行い、システムメンテナンスタイミングの調整を行った上で東京リージョンへの「③切戻処理」を行います。
この①及び③で発生するサービス断時間を最小化することを目的として、今回ご紹介する仕組みを構築しております。

システム全体構成

システムの全体構成

今回のシステム構成の主な特徴は以下4点です。

①Amazon RDS(Amazon Aurora)は東阪でグローバルデータベースを構成し、通常時は東京リージョンにライターが存在
②Cassandra及びAmazon RDS(Amazon Aurora)のDBは東京-大阪間でデータを同期
③大阪リージョンのAkka(*1)は平常時は停止状態 (*2)
④オンプレミス環境と業務系通信の接続を実施

*1 Akkaはアプリケーションを構築するためのライブラリの役割を果たすリソースであり、以降「アプリケーション」と表現する。
*2 東阪リージョン間でAkkaクラスタを構築すると、リージョン間通信のレイテンシにより、障害の誤検知を行う可能性あり。そのため一貫性を重視しActive-Standbyの方式を選択。

今回のシステムでアプリケーションと、データベース機能を担うCassandraでは東阪の同期において一貫性を重視するため今回のシステム構成としてはActive-Active構成ではなくActive-Standby構成を採用しております。

Lernaのより詳細な情報に関しては以下をご参照ください。
https://fintan.jp/page/503/

切替時の主な考慮事項

今回の構成においてリージョン切替ではDNSの切替に加え、Amazon RDS(Amazon Aurora)およびCassandraの制約から主に以下に対する考慮と対応が必要です。

①Amazon RDS(Amazon Aurora)は大阪側をプライマリクラスタとする切替処理を手動で実行する必要がある。
②大阪アプリケーションの起動処理を行う必要がある。
③東阪のNWを分断し、大阪単独で稼働している状態にする必要がある。

考慮事項に対する検討結果

考慮事項に対するアプローチとして、以下の対応を行うことで対応しております。

リソース 考慮事項 検討結果
Amazon RDS グローバルデータベースからセカンダリクラスタ(大阪)を強制的に切り離し、スタンドアロンクラスタに変更する。
アプリケーション ②・③ 東阪Cassandraの疎通をNACLの設定変更で遮断、大阪側のCassandraのみで稼働可能な状態とする。

上記を迅速かつ確実に実施することを考慮して、責任者による切替判断を経て半自動処理で速やかに且つ安全な切替を行うことを目指しました。

切替の実施内容

切替処理で行っている内容は以下の通りです。

No リージョン リソース 実施項目 自動化対象
1 大阪 Cassandra 東阪通信の切断 ※1
(NACLによる通信遮断)
2 大阪 Amazon RDS グローバルデータベースの分離 ※2
3 大阪 Amazon RDS RDS設定変更
(マスタクラスタの書き換え)
4 大阪 AWS SystemsManagerパラメータストア Systems Manager Parameter Storeの設定値書き換え ※3
5 大阪 Akka⇒AWS Fargate(オンライン) アプリケーション起動
6 大阪 Batch⇒AWS Fargate(バッチ) Batch機能有効化
7 大阪 SystemsManager
パラメータストア
Systems Manager Parameter Storeの設定値書き換え ※4
8 大阪 Amazon Route53 DNSレコード書き換え
9 東京(オンプレミス) Akka⇒AWS Fargate(オンライン) アプリケーション起動

上表のNo8においてDNSのレコード書き換えを手動としている理由について、今回構築したシステムの特性上、システムリリース後にDNSレコードの追加が随時発生することが見込まれております。その都度切替処理の仕組みに対しても、同様のDNSレコードの内容を反映させ続けることは運用負荷が高く、また設定漏れによる切替失敗のリスクを避けるために手動としました。

<補足事項>
※1:通常、Cassandraは東阪でレプリケーションを行っています。NACLの機能で東阪の相互通信をdenyとすることでこの通信を遮断し大阪単独での稼働を可能にします。
※2:大阪クラスタをマスタDBにするためにグローバルデータベース構成から離脱させて、スタンドアロン構成とします。
※3 ※4 :Akkaクラスタの構成前後でAWS Systems Manager Parameter Storeに設定する設定値が一部異なるためアプリケーションの起動前と後でそれぞれ適正な値を設定します。

切替時の全体構成イメージ

DR切替にて使用した自動化ツールの概要

今回のリージョン切替処理/切戻準備の実施項目において、自動化対象になっている項目は全てAWS Step Functionsステートマシンの中で実行します。ステートマシンはネスト構造を採用しております。
ネスト構造は下記図の通り、上位マシンを実行すると上位マシン内に組み込まれている下位マシンがそれぞれの下位マシン内に設定している処理を順番に開始する構造になっています。
下位マシンは基本的に更新系処理を1つだけ配置する構成とします。例えばAmazon EC2起動操作を行う場合、EC2起動処理(更新系処理)+起動確認(参照系処理)の組み合わせで1つの下位マシンと定義します。

ネスト構造のメリットとして、上位マシン実行時に処理に失敗した下位マシンがあった際(下記図①)、失敗した下位マシンを直接再実行する(下記図②)ことで失敗した処理から再開することが可能となります。2023年2月現在、AWS Step Functionsには処理の途中から再実行する機能が無いためこのような構成を採用しております。

切替時に使用した自動化ツール

前述した実施項目に合わせて、どのようなステートマシン構成としているかを以下に記載します。

No 実施項目 自動化対象 下位マシン
1 東阪通信の切断
(NACLによる通信遮断)
A
2 グローバルDBの分離 B
3 Amazon RDS設定変更
(マスタクラスタの書き換え)
C
4 Systems Manager Parameter Storeの設定値書き換え
(アプリケーション起動時参照値)
D
5 アプリケーション起動 E
6 Batch機能有効化 E
7 Systems Manager Parameter Storeの設定値書き換え
(アプリケーション起動後参照値)
D

上位ステートマシンの構成

※あくまで概略図であり、一部の処理・分岐を割愛しています。

本記事では切替処理について詳細を記載致しましたが、切戻準備及び切戻処理についても同様にAWS Step Functionsを利用して自動化を実現しております。
切替ツールにAWS Step Functionsを採用したことで、ツール開発におけるコーディング量を大幅に縮小することができ、更に実行状態が可視化されていることや各処理時点のインプット・アウトプットがマネジメントコンソール上で確認できることなどから、テスト工数削減を実現することができました。

切戻の効率化

ここまで解説してきた内容で切替処理を迅速に行うことができるようになりました。その後、東京リージョンの復旧を待って切戻を実施していきます。切戻当日の作業を最小限にして確実に切戻を成功させるため、大阪リージョンでの業務継続期間中に切戻準備作業を実施します。切戻準備で行う作業は全て業務処理に影響を与えないものですが、作業項目が多岐にわたるためこれも自動化しております。具体的に切戻準備で行っている作業項目は以下の通りです。

No リージョン リソース 実施項目 自動化対象
1 大阪 Amazon RDS グローバルデータベース構成の作成
2 大阪 Cassandra Cassandraクラスタの分離(東京除外) ※5
3 東京 Akka⇒AWS Fargate(オンライン) アプリケーション停止
4 東京 Batch⇒AWS Fargate(バッチ) Batch機能無効化
5 東京 Cassandra Cassandra停止
6 東京 AWS SystemsManagerパラメータストア Systems Manager Parameter Storeの設定値書き換え ※6
7 大阪 Cassandra 東阪通信の復旧
8 東京 Amazon EBS Cassandra用空データのEBSボリューム作成 ※7
9 東京 Cassandra Cassandra起動
東阪Cassandraレプリケーション再開
10 東京 AWS SystemsManagerパラメータストア Systems Manager Parameter Storeの設定値書き換え ※8

<補足事項>
※5:東京リージョン側の操作が出来ない期間は東阪のネットワーク分断による一時対応を行っていますが、東京リージョン復旧後はクラスタからの除外対応を行うことで根本対応を行います
※6 ※8:Cassandraクラスタ構成時に参照する値、及びクラスタ構成完了後ノード障害発生時にクラスタ構成を保つための値を設定します
※7:一度クラスタ構成から離脱(除外)をした後は東阪でのデータ不整合を避けるため空のEBSボリュームをCassandraインスタンスに付け替えることで対応します

実施内容概要図

切戻準備の全体構成イメージ

上記を行うことで切戻に向けた環境準備が整ったことになります。その後にメンテナンスタイミングを調整し切戻処理を行います。本記事では割愛しますが、切戻処理に関しても切替処理と同様の仕組みを実装することで、サービス断時間を1時間以内に収めることができています。

今後に向けて

今回開発したDR切替用自動化ツールを使用することで、本システムで定めている「切替判断後1時間以内に切替を実施する」という目標を達成することができました。更にDR切替といういつ発生するか分からない事象に対して、通常の運用体制の中で確実に作業実施ができるようツール及び手順を整備し、テストで品質を担保できていることは我々にとって自信をもってサービス提供できる源泉ともなっています。
Lernaは業界を問わずミッションクリティカルなシステムに利用できるソフトウェアスタックであり、今回迅速なリージョン切替が可能になったことでLerna+AWSの構成により低コストで高い可用性を実現することができるようになったと考えております。
今回記事の中で紹介した切替・切り戻しの仕組みはAWSのサービス群を用いて構成していることから、他システムへの横展開も容易に行うことが可能です。
今後我々としては、今回実現した仕組みを定型化して多くの自社サービスやお客様に提供することで、ミッションクリティカルが要求されるシステムの実現方式の選択肢に加えて頂けるようにしていきたいと考えております。

著:TIS株式会社
DXビジネスユニット ペイメントサービスユニット
ペイメントプラットフォームサービス部
主査 二出川 弘

Modis株式会社
営業統括 ICT Solution事業本部
嶋沙織

PAGE TOP

サービスに関する資料をご希望の方は、フォームに必要事項を入力いただき、ご送信ください。

資料を請求する

お問い合わせ
各種お問い合わせページ
お問い合わせフォーム
サービスに関するお問い合わせ
お電話
0800-600-9810
携帯電話
050-5816-9805
受付時間 9:00~12:00 13:00~17:00(土・日・祝日を除く)

更新日時:2024年3月25日 16時39分