re:Invent 2024: ブラジル裁判所のAWS緊急移行 - 21日間の挑戦
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Braving the storm: TJRS’s 3-week cloud migration amid disaster (WPS205)
この動画では、Brazilの裁判所が大洪水に見舞われた際に、データセンターの浸水によってシステムが停止する危機に直面した事例を紹介しています。35万人のユーザーを抱える重要システムeprocを、わずか21日間でAWSクラウドへ移行した取り組みについて、技術的な課題とその解決策を詳しく解説しています。AWS DMSやAWS DataSync、Amazon Auroraなどの活用方法や、100台以上のVMの移行手法、3億8,400万以上の文書の移行プロセスなど、具体的な技術的知見が示されています。また、AWS Disaster Responseによる支援体制や、危機的状況下でのリーダーシップ、チームマネジメントの教訓も共有されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
災害時のIT部門リーダーの挑戦：Porto Alegre裁判所の事例
皆様、こんにちは。本日のセッションにご参加いただき、ありがとうございます。皆様に一つお伺いしたいのですが、あまりにも大きな課題に直面し、失敗が許されない状況に置かれたことはありますでしょうか？本日はそのようなケースについてお話しさせていただきます。まず、簡単に自己紹介をさせていただきます。 私はIT業界で25年以上の経験があり、そのうち12年間をPorto AlegreのCourt of Justiceで過ごしてきました。そして8ヶ月前にCIOに就任いたしました。
皆様、こんにちは。私はRafael Bitencourtと申します。Brazilにおける政府チームを率いる立場にあり、このチームは政府機関との関係管理を担当しています。本日、この事例を皆様と共有できることを大変嬉しく思います。私はAllyson Oliveiraと申します。AWSのSolutions Architectとして、お客様のニーズを理解し、最適なソリューションを提供することを主な使命としています。
本プレゼンテーションでは、私たちが実施した移行のステップ、直面した課題、そしてこの過程で得た教訓を中心にお話しさせていただきます。その後、AWSがどのようなサポートを提供し、それがこのプロセスでいかに重要であったかについて概要をご説明します。また、移行プロセスを成功に導いたAWSソリューションについてもご紹介いたします。最後に重要なポイントをまとめ、質疑応答の時間を設けさせていただきます。
これは6ヶ月前、市の歴史上最大の洪水に見舞われた際の私のデスクの様子です。この1時間で、災害の中でCourt of Justiceのオンラインサービスを維持するという課題について、皆様とご一緒に見ていきたいと思います。リーダーシップとレジリエンスについて、私たちが苦労して学んだ教訓をお伝えします。また、この規模のクラウド移行に関連する技術的な課題と、それぞれの障壁をどのように克服したかについてもご説明いたします。
しかし、その前にBrazil南部のPorto AlegreにあるState Court of Justiceをご紹介する動画をご覧いただきたいと思います。 ご覧の通り、
洪水危機下でのクラウド移行：21日間の奮闘と教訓
裁判所は、特に他のすべてが崩壊しているように見える状況においても、24時間365日利用可能でなければなりません。Rio Grande do Sulの州全体が豪雨と洪水の影響を受けました。この災害の中で、システムを稼働させ続け、市民にサービスを提供し続けることが私たちの課題でした。DV犯罪や健康問題に関する案件が増加していました。
その時点での私たちの状況はどうだったのでしょうか。2つのデータセンターがありましたが、どちらもシステムを稼働させることができない状態でした。1つ目は浸水し、2つ目は水に囲まれ、発電機で運転していました。水位は上昇を続け、燃料の補給も困難な状況で、運用の継続は不可能でした。
私たちが直面した技術的な課題を簡単にご説明します。eprocは約35万人のユーザーを抱える私たちの最重要システムです。3億8,400万以上の文書、10テラバイトのデータ、100台以上のサーバー、そして46以上のシステム連携を有しています。このスライドでは、メインデータセンターの電源設備の状況をご覧いただけます。私たちは素早く考え、行動しなければなりませんでした。
これが5月の私たちのタイムラインです。緑の線は、周辺地域を浸水させた川の水位の急激な上昇を示しています。このような危機的状況では、素早く考え、迅速に決断を下さなければなりません。必要な情報がすべて揃っていない状況でしたが、5月2日、水位が急上昇する中、メインデータセンターが浸水していたため、2つ目のデータセンターをプライマリに切り替えることを決定しました。翌日、水は裁判所の建物に達し、私たちは避難を余儀なくされました。5月4日には、停電の警告により両方のデータセンターを停止せざるを得ませんでした。24時間にわたり、すべてのシステムが停止しました。
システムがオフラインになることの影響は甚大でした。私たちは迅速に行動する必要がありました。翌日、eprocをクラウドに移行することを決定しました。その後の数日間で、わずか21日という驚くべき短期間でシステムを完全に稼働させることができました。
この取り組みから私たちが学んだ教訓をご紹介します。1つ目は、問題を小さな単位に分割し、それぞれに責任者を置いて担当させることでした。私たちは5つのSquadに分けました：Application、Financial、Database、Documents、そしてIntegrationです。これらについては後ほど詳しく説明します。
2つ目の教訓は、ソリューション志向のリーダーを選ぶことでした。危機的な状況下で、多くの懐疑的な意見に直面しました。何が悪くなるかを考える人々ではなく、ソリューション志向の前向きな考え方ができる人材が必要でした。
この写真をご覧ください - これは私たちのインターネットプロバイダーの状況を示しています。彼らも電力のない非常に危機的な状況にありました。彼らは素早く考え、行動しなければなりませんでした。このプラットフォームは一晩で構築されました。これがなければ、私たちはクラウドにデータを送信することができなかったでしょう。
リーダーとして、クラウドへの移行前に、成功を確実にするための代替案を考えなければなりません。各Squadに対して、目標達成のための複数の方法を検討しました。本番移行の2日間も、何か問題が発生した場合のPlan Bを用意していました。残念ながら2回失敗しましたが、幸いにもPlan Bがありました。ここでの教訓は、危機的状況では成功するためにPlan B以上の準備が必要だということです。
21日間を通じて、コミュニケーションが鍵となりました。 ITチーム全体と経営陣は様々な場所からオンラインで参加していました。私たちは経営陣との日次チェックポイントを1日3回（早朝、昼、夕方）設けました。ITチームは日中会議を行い、夜間も24時間体制で発電機の燃料補給を行う人員がオンラインと現場で作業していました。危機的状況では、全員が自分の役割の重要性を理解することが成功への必須条件となります。
もう1つの教訓は、適切なパートナーを選ぶことです。 プロジェクトの遂行には、関係者全員が一致団結することが不可欠でした。AWSは私たちが成功するために必要なサポートを最初に提供してくれました。SERPROはプロジェクト開始当初からのパートナーでした。Hitachi Vantaraは、サーバーからクラウドへのオブジェクト移行を支援する上で重要な役割を果たしました。 最後の教訓は、どんなハイパフォーマンスチームにおいても最も重要な要素である「目的」です。チームメンバー全員が洪水の影響を受けていました。私のチームの全員が、仕事と家庭の両面で危機的な状況に直面していました。家を失った人もいれば、避難している友人や家族を助けなければならない人もいました。さらに、このプロジェクトの開始直後に、主要メンバーの1人が父親を亡くしました。
リーダーとして、チームメンバーが直面しているこれらの困難や苦しみを認識しながら、どのようにして必要な行動を促すことができたのでしょうか？答えは、目的を持つことでした。私たちの目的は、司法サービスをオンラインで維持し、市民が最も必要とする時にサービスを確実に提供することでした。 最後に、RafaelとAllysonに具体的な作業内容の説明を譲る前に、1つ申し上げたいことがあります。もし誰かが1ヶ月以内にこれら全てを実現できると言っていたら、私は信じなかったでしょう。明確に定義された目的と、適切なパートナーに支えられた優秀なチームがあったからこそ、可能になったのです。
AWS Disaster Responseプログラム：危機時のクラウドサポート
Vanessaさん、ありがとうございました。素晴らしく感動的なストーリーでした。8ヶ月前にこの経験を共にしたチームの一員であることを誇りに思います。しかし先に進む前に、Vanessaさんに一言申し上げたいと思います。この災害を通じてチームを導いてくださった姿は素晴らしかったです。常に示してくださった強さとご指導が大きな違いを生み出しました。その時共にいてくださり、また本日もご参加いただき、ありがとうございます。続ける前に、皆さまにお聞きしたいのですが、AWS Disaster Responseのサポートについて聞いたことがある方は手を挙げていただけますか？...わずか12人ですね。だからこそ、今日はこのプログラムについてご説明させていただきます。 AWS Disaster ResponseはAWS組織内の戦略的な柱であり、社会的責任と影響力を持つ取り組みです。
このチームは、危機的状況下にある顧客、組織、そしてコミュニティを支援するというミッションのもと、研究開発を行い、プロセスとパートナーシップを維持しています。国連の推計によると、2023年までに世界人口の半分が、洪水、暴風雨、津波のリスクが高まる地域に住むことになるとされています。これらの災害は気候変動の影響で、過去4年間で発生頻度が3倍に増加しています。このチームは、クラウド技術と汎用技術の高度な活用を通じて、組織やエコシステム内の他のアクターが被災者支援を提供できるよう支援しています。
このサポートは様々な形で提供されます。AWSは、災害対応が必要な状況下でクラウドへのアクセス障壁を取り除くためのクレジットを提供することができます。さらに、AWSは人道支援に関連するギャップを特定し解決するためのイノベーションに投資しながら、災害対応時のサポートを提供しています。最後に、このような危機的状況下でのシステム移行プロセスを支援するための技術的なガイダンスと専門的な技術サポートを提供することができます。
専門的な技術サポートについてより詳しく見ていくと、活用できる層がいくつかありますが、時間の都合上、ここでは3つだけご紹介します。1つ目はAWS Professional Servicesです。これは、AWSクラウドに関する深い知識を持つ経験豊富な専門家グループで、通常はアーキテクチャ、セキュリティ、信頼性に関する重要な判断に関わっています。今回の案件では特に、失敗する時間的余裕がなかったため、重要な判断に関与していただきました。AmazonとAWSのCEOが言ったように、「経験値には圧縮アルゴリズムがない」のです。ここでは経験が重要なカギとなります。
AWS Solutions Architectチーム（ここではAllysonが代表）も同様に深い知識を持っていますが、彼らの目的は顧客固有のニーズを理解し、その顧客に特化したソリューションとガイダンスを提供することです。Allysonは数ヶ月前からこの案件に携わっており、重要な側面をいくつか紹介することができました。最後になりますが、同様に重要なのがパートナーです。AWSは世界中に何千ものパートナーを持ち、ブラジルだけでも何百ものパートナーがいます。これらのパートナーは、ビジネスの拡大と、私たちのチームやお客様のミッション達成を支援する上で重要な存在です。
緊急クラウド移行の技術的課題と解決策：AWSアーキテクトの視点
ということで、Allysonをステージにお迎えしたいと思います。ありがとう、Rafael。あの状況について連絡をもらった時のことを覚えています。土曜日の朝、コーヒーを入れているときに電話がかかってきて、こう言われました：「Allyson、裁判所のデータセンターが浸水する可能性がある」と。この言葉が、その後2週間の移行作業の指針となりました。移行の計画を立て始めた時、まず考えたのは、移行の前中後で解決すべき主な技術的課題でした。その詳細についてお話ししますが、まずは簡単な振り返りをさせてください。
この裁判所はブラジルで4番目に大きく、1,000万件以上のアクティブな案件を抱え、オンプレミスのMySQLに大量のデータとオブジェクトを保存し、100以上のVMを稼働させていました。移行時点では、このアプリケーションはクラウドネイティブではなく、CI/CDもコンテナソリューションも導入されていませんでした。スケジュールは非常にタイトで、多くの不確実な要素がありました。ご覧の通り、複雑なシナリオでしたが、複雑なシナリオでは物事が常に計画通りに進むわけではありません。
今朝のCTOのWerner Vogelsによるキーノートでも言及されていましたが、「すべてのものは常に失敗する」のです。私たちは失敗に備える必要があります。なぜなら、たくさんの計画を立て、多くのタスクを作成したとしても、複数の環境シナリオでプロジェクトを実行する際には、物事は計画通りには進まないからです。私たちはプランA、プランB、時にはプランCを用意し、3つの主要な技術的課題に直面しました。
最初の課題は、オブジェクトの移行方法でした。まず、製品におけるオブジェクトとは何かについて説明させていただきます。eprocにおけるオブジェクトとは、プロセスに関連付けられているすべてのものを指します。それは文書、動画、写真などであり、これらのファイルはすべてオンプレミスのストレージに保存されています。このオンプレミスストレージには、Amazon S3に似たAPIアクションがいくつかありました。Amazon S3には150以上のAPIアクションがありますが、私たちのストレージにはわずか15しかありませんでした。Amazon S3ほどの機能はありませんでしたが、すべてのデータをコピーしてS3に移行するための初期スクリプトを作成しました。しかし、司法システムは止まることなく稼働し続け、ファイルも更新され続けています。そこで、オンプレミスストレージ上で更新されたファイルをどのように処理し、AWSに移行するかを検討する必要がありました。
この課題を解決するために、AWS DataSyncを使用しました。AWS DataSyncは、すべてのファイルを比較して変更されたファイルを特定するサービスです。変更されたファイルを見つけると、そのデータをS3にコピーします。初期スクリプトの実行には10日から15日ほどかかり、さらに変更分のファイルをコピーするのに1、2日かかりました。すべてのアクションは並行して実行され、このようにしてデータを移行しました。次の課題は、データベースの移行方法でした。裁判所には10テラバイト以上のデータを持つMySQLデータベースがありました。最初に採用した戦略は、AWS DMS（Database Migration Service）の利用でした。DMSは、マネージド型のデータベース移行サービスです。オンプレミスのストレージからデータをコピーし、AuroraやRDSなどのデータベースにそのデータを挿入します。DMSでデータのコピーを開始しましたが、やはり司法システムは止まることなくオンラインで稼働し続けていました。
AWS DMSジョブは、まずファイルのコピーだけを開始し、ジョブが完了した後、データベース上のデータとオンプレミスストレージ上のデータを比較しました。いくつかの相違点が見つかり、スコープに問題があったため、機能が完全には一致しない状況がありました。DMSのプランBとして、Perconaソフトウェアでバックアッププランを作成し、そのバックアップをAmazon S3のバケットにアップロードして、Amazon EC2インスタンスに保存することにしました。この仮想マシンに接続し、MySQLをインストールしてバックアップを開始しました。
EC2インスタンスでバックアップを開始した後、このバックアップをオンプレミスサーバーと同期させました。同期が完了すると、AWS上に整合性のあるコピーができましたが、このデータベースをAuroraに移行しようとしたところ、うまくいきませんでした。これは、オンプレミスのMySQLデータベースのバージョンがAmazon Auroraと異なっていたためです。そこで、中間段階としてMySQL RDSインスタンスが必要になりました。RDSは、MySQLを実行するAWSのマネージドサービスです。RDSにデータを移行し、RDSインスタンスを再度同期させた後、Auroraに移行しました。
最初の戦略はDMSを使用することでしたが、実際に機能した二番目の戦略は、RDSとAuroraを使用することでした。Auroraを選択したのは、多くの利点があったからです。I/O処理が少なく、ネットワークパケットを最小限に抑えることで、レイテンシーパスを削減し、お客様により高いパフォーマンス、信頼性、効率性を提供します。もう一つの利点は、単一のエンドポイントでデータベースにアクセスできることです。トラフィックをWriter インスタンスとReader インスタンスに分割し、Readerインスタンスをスケールアップして、同じ共有クラスターストレージボリュームにアクセスすることができます。
これらの利点を踏まえ、私たちはシステムのデータベース層にAuroraを採用することにしました。データベースに関する2つの課題を解決した後、3つ目の課題はサーバーの移行方法でした。顧客は100台以上のVMを保有していましたが、それらはクラウドに対応していませんでした。自動インストールやスクリプトコードがなく、古いOSパッケージを使用していたのです。このような状況で、環境をテストする時間は非常に限られていました。Plan Aとして、インスタンスを作成して製品をインストールするという新規インストールを試みましたが、うまくいきませんでした。QAチームは別のタスクに時間を取られており、この最初の計画でいくつかの問題に直面しました。
Plan Aはシンプルでしたが、うまくいかなかったため、Plan Bに移行しました。Plan BではOVA（VRからのファイル）を使用します。顧客は仮想マシンをホストするためにデータセンターVRを持っていました。Plan BではOVA（VHDとVMDK）を取得して変換します。OVAのディスクをキャプチャしてAmazon S3に保存し、そのOVAをAMI（Amazon Machine Image）に変換する別のスクリプトを実行するコードを作成しました。AMIがあれば、多数のEC2インスタンスを起動できます - 1つのAMIで100台のVMを起動することができます。このケースではPlan Bがうまく機能し、データの移行とサーバーの作成後、最終的なアーキテクチャが完成しました。
AWSのセキュリティは私たちの最優先事項です。私たちは常にセキュリティ層を考慮してアーキテクチャの設計を始めます。最初のサービスはAWS WAF（Web Application Firewall）で、Layer 7攻撃からアプリケーションを保護します。AWS ShieldはDDoS攻撃の防御と緩和を担当するサービスで、システムのダウンタイムを防ぎます。3番目のサービスはAmazon Route 53で、DNSとランダムなスパイクトラフィックの処理を行います。4番目のサービスはAmazon GuardDutyで、アカウントの異常な動作を検出するAIセキュリティサービスです。
セキュリティ層の次は、システムの回復力と安全性を高めるために3つのゾーンに分かれたインフラストラクチャ層です。最初のサブネットには、サーバーへのリクエストをルーティングするApplication Load Balancerを持つパブリックサブネットがあります。2番目のサブネットには、EC2アプリケーションが稼働するプライベートサブネットがあります。私たちのシステムはこれらのサブネットでEC2上で動作し、3番目のサブネットはAuroraとデータベースレプリカを実行するデータベースサブネットです。これらはすべて3つのアベイラビリティーゾーンにまたがって配置されています。
最後の層では、システムのキャッシングを担当するAmazon ElastiCache、Amazon EC2インスタンス間で共通のストレージファイルを共有するAmazon EFS、オブジェクトを保存するAmazon S3などの中間システムが稼働しています。このAWS環境全体が、顧客のデータセンター（サーバーやデータベースを含む）と接続されています。
重大な出来事を乗り越えることは大変なことですが、そこから回復力が生まれることも多いものです。十分な事業継続計画を立てていても、自然災害は想定したシナリオを超えることがあります。チームを成功に導くのは、効果的な指針を持った強力なリーダーシップ、迅速な意思決定、明確で一貫性のあるコミュニケーション、臨機応変に優れたソリューションを生み出す能力、そして何よりもミッションへの強い意志です。私たちのミッションは司法システムをオンラインで維持することでした。そして危機的状況の中で、システムが停止したのはわずか24時間だけでした。
こちらが私たちの連絡先情報です。ご不明な点やご質問がございましたら、お気軽にご連絡ください。本日はご参加いただき、誠にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion