Intuit 社の導入事例: オンプレミス MySQL から Amazon Aurora への移行の自動化

パブリッククラウドとなると、Intuit にこれ以外の選択はありません。実際に、Intuit では AWS を急ピッチで導入しているところです。私たちは、当社のレガシーデータセンターを売却し、顧客向けアプリケーションである QuickBooks、TurboTax、および Mint を AWS に移動させており、今後数年の間には完全に移行させる予定です。

データベースは、Intuit のアプリケーションの多くにおいて中核をなすものです。データベースチームは、移行し、その後クラウド内で運用するために、どのアーキテクチャを標準とするか、そしてどのランブックとツールを構築するかについて考えをまとめてきました。Intuit では、これらの問題を解決する最も早い方法が、既存のオンプレミスアプリケーションのひとつを取り上げて、それを実際に Amazon Aurora に移行してみることだという結論に達しました。

このブログ記事では、以下についてお話したいと思います。

アーキテクチャを決定するために用いた主な原理と Aurora を選択した理由
ダウンタイムを最小限に抑えた移行へのアプローチ方法、学んだ教訓、および問題の対処方法
私たち、または他の人が繰り返して使用できるように、プロセスの一部を、特に SSL 環境のために自動化すべく移行中に開発したツール

私たちが移行用に選択したアプリケーションは、MySQL で実行される Test Execution Platform (TEP) です。TEP は当社製品の多くに対するフックを持つ一元化されたテストプラットフォームで、Amazon Aurora への移行に最適な候補でした。それに関連付けられた他のアプリケーションも Aurora に移行されています。

どのデータベースアーキテクチャを使用するか?

AWS への移行前、当社のデータプラットフォームは、以下の図にあるように、Intuit Hosted Platform (IHP) データセンター内で実行されていました。データセンター内、そして 2 ヶ所の地理的地域の間には優れた可用性があり、高可用性の実現には MySQL のバイナリログ (binlog) ベースのレプリケーションを活用します。

AWS 移行前の Intuit データプラットフォーム

AWS に関するオプションを評価する際、私たちは以下の 2 つのアプローチについて議論しました。

リフト＆シフト、つまり Amazon EC2 インスタンスで独自に MySQL サーバーを実行する (自己管理型)
完全マネージド型のクラウドネイティブプラットフォームに移行する

私たちは、クラウドソリューションが現在のソリューションよりも良い結果を出すことを望んでおり、データベースメンテナンス工数を少なく保ち、全体的なインフラストラクチャコストを削減し、さらにきめ細かく信頼性の高いバックアッププロセスとリカバリプロセスを作成して、ダウンタイムを減らしたいと考えていました。これらの理由により、私たちは完全マネージド型データベースを使用することに決定しました。また、次のイノベーションの波でアプリケーションチームと力を合わせることができるように、データベースチームの時間を解放したいとも考えていました。

Amazon RDS for MySQL または MySQL との互換性がある Amazon Aurora の選択

次に、私たちは Amazon RDS for MySQL、または MySQL との互換性がある Amazon Aurora のどちらを使用するかを決定する必要がありました。どちらも AWS の完全マネージド型サービスで、それぞれのソリューションに長所と欠点がありました。Aurora は、より短いレプリケーション遅延、自動化されたストレージ拡大、より優れたスループット、およびサーバーレスデプロイメントモデルなどの高度な機能を、RDS MySQL よりも数多く備えています。しかし、RDS MySQL が GTID レプリケーションをサポートする一方、Aurora はまだそれに対応していません。私たちは Aurora MySQL を使用することに決定し、GTID サポートの欠如については、それが必要とされる箇所で AWS Database Migration Service (DMS) を使用することによって対処することができました。

AWS への移行時における Intuit データプラットフォーム

PoC

Intuit の最終的な目標は、TEP データベースをデータセンターから MySQL 5.6 との互換性がある Aurora に移行することでした。PoC のため、私たちはまず、移行の試行とアクティビティのプロダクションデータベースへの影響を和らげるためにオンプレミス環境を Amazon EC2 で実行される MySQL サーバーにレプリケートしました。次に、Amazon EC2 で実行される MySQL サーバーから Aurora への移行を実施しました。Amazon EC2 と Aurora の間でレプリケーションが期待通りに機能したことを検証した後、オンプレミスから Aurora への直接的なレプリケーションを設定しました。移行中は、レプリケーションのために SSL が有効化されていることを確実にしました。

学んだ教訓

移行プロセス中にはいくつかの問題が発生しましたが、それらの対処方法について説明したいと思います。

OpenSSL ライブラリバージョンの互換性
公開/秘密暗号鍵基盤と電子証明書で作業を行う時は、証明書の作成またはインポート中に問題が発生すると、レプリケーションパートナー間の接続の喪失、ひいてはアプリケーションのダウンタイムにつながる場合があることから、注意する必要があります。

私たちは、MySQL 5.6 との互換性がある Aurora に対して、MySQL 5.6.24 を実行するオンプレミスデータベースから SSL を使ってレプリケートすることができないという問題にぶつかりました。考えられる原因を排除しようと何回か試みて、それらが不成功に終わった後、私たちは AWS サポートに問い合わせました。AWS サポートへのパケットトレースの提供は、私たちが問題を見極めるために役立ちました。これは、Aurora と当社オンプレミスデータベースサーバー間における互換性のない OpenSSL バージョンによって生じた問題でした。私たちは OpenSSL 1.0.2j-fips を使用していましたが、これには Aurora がサポートするバージョンである FIPS 非準拠バージョンの 1.0.2k 以降との互換性がないことがわかりました。OpenSSL 1.0.2k は MySQL 5.6.36 の一部でもあります。他の互換性問題のリスクを減らすため、私たちは当社のオンプレミスデータベースサーバーを MySQL 5.6.36 にアップグレードすることにしました。

CA 証明書の作成時における CN 名の指定
Aurora には関係のないことですが、私たちは、証明書を作成するとき、コモンネーム (CN) に適切なサーバー名とクライアント名を指定するのではなく、デフォルト値を選択するという間違いを犯しました。これによって抽象エラーが生じ、解明するまでしばらく時間がかかりました。デフォルト CN 名を受け入れるのではなく、有効な名前を提供するようにしてください。

Binlog 保持がデフォルトで NULL に設定されている
他の MySQL ベースのデータベースエンジンとは異なり、Aurora はクラスターの高可用性について binlog に依存しません。デフォルト設定では binlog は有効化されておらず、binlog レプリケーションを実行したい場合は、明確に有効化して設定する必要があります。以下のストアドプロシージャを使用して、適切な binlog 保持値 (Intuit の場合の 6 日など) を設定するようにしてください。

CALL mysql.rds_set_configuration(‘binlog retention hours’, 144)

セキュリティ関連の考慮事項

私たちは、エンドツーエンドセキュリティを確実に実施したいと考えていました。以下は、セキュリティコンポーネントのそれぞれに対して行った事柄です。

接続検証: ホスト名の ID 検証を有効にする
保管時のデータの暗号化: 当社独自のカスタマーマスターキー (CMK) を活用する AWS Key Management Service (KMS) を使った Aurora 向けのネイティブ暗号化
クライアント接続のための転送時のデータの暗号化: データベースユーザーに対する SSL 接続の実施
レプリケーション中のデータの暗号化: SSL で暗号化された接続を使用する

接続を暗号化するために SSL を使用するよう Amazon Aurora を設定する時は、すべてのリージョンで機能する証明書バンドルではなく、AWS によって発行されたリージョン固有の中間証明書の使用をお勧めします。これによって、追加の分離レイヤーが提供され、複数のリージョンを利用する場合のセキュリティをさらに向上させることができます。

モニタリングと管理

Aurora 固有のメトリクスを監視するために、私たちは Amazon CloudWatch と、拡張モニタリングおよび Performance Insights などのネイティブの Aurora モニタリング機能を活用しました。Intuit では、社内で開発した数多くのツールとサードパーティーツールも使用しています。私たちの目標は、Aurora のプロビジョニング、モニタリング、ロギング、およびポリシー実施を自動化するために、これらのツールに接続することです。

移行クックブックとオートメーション

オンプレミスから Aurora への SSL ベースの移行を自動化するための既成のスクリプトとツールをなかなか見つけられなかったため、私たちはそれらを独自に開発しなければなりませんでした。この件における皆さんへの朗報は、これらのスクリプトを GitHub で利用できるようにしたことです。以下は、私たちが行った移行手順のおおまかなウォークスルーです。また、該当箇所では、手順を自動化するために当社が作成したスクリプトを強調表示しました。各手順における作業の詳細は、GitHub のこの文書で説明しています。

パート I: AWS でのレプリケーションスレーブのセットアップ

ネットワークアクセスコントロールリスト (NACL) が、ポート 3306 について Aurora とオンプレミスホスト間でオープンになっていることを確認します。
新しい Aurora インスタンスを作成します。この手順を自動化するために、私たちは AWS CloudFormation テンプレートを作成しました。

パート II: オンプレミスでのレプリケーションマスターの設定とレプリケーションの有効化

暗号化証明書を生成します。このスクリプトはこちらにあります。
SSL を有効にしたレプリケーションユーザー「repl_aurora」を作成します。
証明書のアクセス許可と所有権を確認します。
my.cnf を使って、オンプレミスの MySQL データベースで SSL を有効化します。
証明書および/またはその位置に変更があった場合は、mysqld プロセスを再起動します。
「SHOW VARIABLES」SQL ステートメントを使って、SSL が有効化されていることを確認します。
手順 2 で作成したレプリケーションユーザーとしてオンプレミスデータベースに接続できることを確認します。
Amazon EC2 ホストまたは Bastion ホストからオンプレミスの MySQL データベースに接続できることを確認します。
オンプレミスから Aurora DB クラスターへの接続があることを確認します。
「SHOW MASTER STATUS\G」を使って、オンプレミスの MySQL データベースから binlog の位置を把握します。
オンプレミスデータベースをバックアップします。Aurora のレプリケーションドキュメントには、バックアップと binlog の位置の整合性を確実にする方法に関する追加の詳細が説明されています。
Aurora DB クラスターにデータベースのバックアップを復元します。
mysqlshow または mysqldbcompare を使用して、Aurora DB クラスターに復元されたデータが正確であることを確認します。
オンプレミスの MySQL データベース用に生成した証明書を Aurora DB クラスターにインポートします。
オンプレミスデータベースサーバーをマスター、Aurora をスレーブとして、それらの間のレプリケーションチャネルを作成します。
「SHOW SLAVE STATUS」SQL ステートメントを使用して Aurora　DB　クラスターのステータスを監視し、レプリケーションプロセスが稼働していることを確認します。
暗号化証明書のローテーション/交換を行う必要があるかどうかを判断します。

パート III: ロールバック目的のための Aurora からオンプレミスデータベースへのレプリケーションのセットアップ

Aurora DB クラスターでレプリケーションユーザー「repl_onprem」を作成します。
正しい RDS 中間証明書をオンプレミスの MySQL サーバーにコピーして、MySQL サーバーを再起動します。
オンプレミスからの「repl_onprem」ユーザーを使用して、Aurora DB クラスターへの接続を確認します。
Aurora をマスター、オンプレミスの MySQL サーバーをスレーブとして、それらの間のレプリケーションチャネルを作成します。
「SHOW SLAVE STATUS」SQL ステートメントを使用してオンプレミスデータベースのステータスを監視し、レプリケーションプロセスが稼働していることを確認します。

右肩上がりの進捗

綿密な評価と移行プロセスを経た後、私たちは Intuit における推奨データベースとして Amazon Aurora を標準とすることに決定しました。

Intuit の社内チームの多くが、Aurora への移行のために、TEP 移行中に私たちが開発したクックブックとスクリプトを活用し始めました。Aurora のようなマネージド型ソリューションでは、そのメリットは単なるコスト節約のみにとどまりません。Intuit のエンジニアチームと SRE チームでは、メンテナンス、アップグレード、およびリカバリの各プロセスに費やす時間が 60～80 パーセントほど少なくなっており、次のイノベーションの波を開発するためにより多くの時間を費すことができるようになりました。さらに、MySQL との互換性がある Aurora は、転送時のデータの SSL 暗号化と保管時のデータの暗号化をサポートします。これは、DBA として、データベースのセキュリティ問題に関する心配事がひとつ減ることを意味します。Intuit が自己管理型の Amazon EC2 データベースサーバーを使用することはないでしょう。

個人的に気に入っている事柄のひとつは Aurora のストレージです。これは、データセットの成長に合わせて 64 TB まで自動的に拡大されます。このため、ストレージサイズの推測、IOPS、そしてストレージの管理について心配する必要がなくなりました。MySQL との互換性がある Aurora の導入におけるメリットを知ったからには、これらすべてを自動化して、夕暮れを浜辺で楽しみたいと思いませんか? 私たちは皆仕事をするために生活していますが、これはその逆になるべきではないでしょうか。

ご質問、ご意見、またはご提案がございましたら、以下からコメントをお寄せください。また、Amazon RDS および AWS KMS に関する AWS フォーラムをご覧いただくこともできます。AWS における暗号化に関する詳細については、「暗号化の基礎」のドキュメント、および、AWS Key Management Service Cryptographic Details のホワイトペーパーをご利用いただけます。PoC において協力してくださった Amazon AWS プロフェッショナルサービスチームの Govi Vanakuru 氏に心から感謝を申し上げたいと思います。

今回のブログ投稿者について

Clement Nappoly 氏は、27 年の IT 経験を持つ Intuit のデータベース管理者です。この 12 年間 Intuit に勤務してきた Nappoly 氏の役割は、過去 5 年の間に SRE へと変化し、 Intuit 全体に対するクラウド移行とデータストアデプロイメントにおけるベストプラクティスを開発して収集する Intuit Platform 組織の一員です。 Nappoly 氏は、Intuit でサポートしているさまざまなデータベースの AWS への移行に向けて取り組んでいます。また、データベースプロジェクトに関するガイダンスと技術面での援助も提供し、AWS を使用するときにそれぞれのソリューションの価値を向上させるための支援をしています。

Amazon Web Services ブログ