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を分断し、大阪単独で稼働している状態にする必要がある。

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

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

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

切替の実施内容

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

上表の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には処理の途中から再実行する機能が無いためこのような構成を採用しております。

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

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

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

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

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

切戻の効率化

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

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

実施内容概要図

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

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

今後に向けて

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

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

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