New Innovations はいかにして研修医管理プラットフォームを Microsoft SQL Server から Amazon Aurora PostgreSQL へ移行したのか
New Innovations はいかにして研修医管理プラットフォームを Microsoft SQL Server から Amazon Aurora PostgreSQL へ移行したのか:
この記事は New Innovations の IT マネージャー、Stephen Sciarini 氏によるゲスト投稿です。
New Innovations が構築してきたビジネスは、すべてがさらに大きな目的 (質の高い医学教育を提供する権限を医療教育者や管理者に与えること) を示唆する共有されたアイデアや信念に基づいています。インテリジェンスは、タスクとテクノロジーを区別しないところまで進歩しており、その結果、医療研修生や教育者は日常の管理義務から解放されます。医療教育分野のパートナーは当社と協力して、この理想的な未来の実現に取り組んでいます。
その未来はそれほど遠くはありません。AWS と Amazon Aurora PostgreSQL のおかげで、当社は顧客の要求を満たすために拡大したインフラストラクチャを構築することができました。AWS Database Migration Service(AWS DMS) によって、Aurora PostgreSQL への移行は、リスクを最小限に抑えながら、顧客と当社のソフトウェア開発者の両方にとってシームレスな体験となりました。AWS DMS を使用し、Microsoft SQL Server の 700 以上のインスタンスを Aurora PostgreSQL に完全に移行しました。さらに、Amazon RDS Performance Insights によってデータベースレイヤーの優れた可視性が得られるため、あらゆる異常に素早く対応することができます。
今日、当社のソフトウェアは世界中に広がっており、病院、メディカルスクール、個人開業医において数多くの医療教育分野に貢献しています。私たちの夢は、医療教育が直面する管理上の拘束から解放された世界です。そうなれば医療機関は、いつか私たちの世代がお世話になる介護者の育成に集中することができます。
2014 年の初めに、Microsoft SQL Server データベースと IIS ウェブサーバーをデータセンターから Amazon EC2 に移行し始めました。その年の 4 月までに、全ワークロードを AWS に移行すると、当社のサイトパフォーマンスが 40％ 以上向上したため、コスト削減とパフォーマンス改善をすぐに実現しました。それは計画された 15 分未満のダウンタイムを達成しながら完了しました。移行の容易さを理由に、Amazon S3 のファイルストレージ、AWS Lambda、AWS WAF、Amazon DynamoDB など他の AWS のサービスの利用をすぐに開始しました。
続いて、ホスティングの決定です。Amazon RDS や独自の EC2 インスタンスの実行など、いくつかのオプションを試しました (この時点ではまだ Aurora PostgreSQL は発表されていませんでした)。AWS はすでに、Amazon RDS で豊富な PostgreSQL サーバーのフリートを起動するのを容易にしていました。そこで当社はすぐにこれを戦略とし、MSSQL のストアドプロシージャと関数を PL / pgSQL に変換することに目を向けました。
多くの場合、関数のパラメータタイプによって、PostgreSQL で動作するようにコードを更新する必要がありました。この更新は、単純なウェブ設定の変更で当社のウェブサーバーを PostgreSQL ドライバーと SQL Server ドライバー間で切り替えられるような形で実行されました。
これは数年前のことですが、当社はスキーマを変換する独自のツールを作成することを決定しました。それ以来、お客様にはスキーマ変換プロセスを自動化するのに AWS Schema Conversion Tool (AWS SCT) を広く採用していただいています。
PostgreSQL にはインデックス、外部キー、トリガを無効にする良い方法がないので、最適なスループットを得るために PostgreSQL のドキュメントに従い、すべてのデータをインポートした後にそれらを加えました。そうすることで、変換後のサーバーでの CPU 使用率は高くなりましたが、変換時間の短縮が必要でした。この負荷を管理するため、同時に 4 つのインデックスのみを適用しました。これにより、余った CPU を実行中の他の変換に充てることができました。
クライアントにとってスムーズでシームレスな体験となるように、私たちはクライアントのデータベースごとにこのプロセスを何度も実践しました。”イージーボタン” の一部は、当社の DevOps エンジニアによって作成されたツールで、変換後のデータの検証もしました。これにより、変換されたデータベースの整合性をチェックし、欠落しているレコードがないことを確認することができました。(AWS DMS はデータ検証機能を発表していませんでした。現在ではこの機能を備えています。)
データ変換プロセス各クライアントのデータベースは平均して数十ギガバイトのデータに変換され、ほとんど 20 分以内に完了します。Amazon RDS を使用した初期テストでは、このプロセスのボトルネックがデータベースへの書き込みスループットであることがわかりました。
平均して、Aurora への書き込みスループットの速さは、従来の RDS の約 3 倍でした。変換プロセスはすぐにこの恩恵を受けました。
Aurora のストレージサブシステムは、必要に応じて自動的に拡張されます。Amazon RDS では、将来のストレージニーズを計画する必要があったため、各サーバーに 1 TB のストレージを作成する必要がありました。Aurora では、使用分だけを支払うので、気にすることなく数ヶ月先までスペースを拡張することができます。
AWS が Aurora 用に提供する最も価値あるツールの 1 つが、Performance Insights です。当社の DBA は日常的にこのダッシュボードを使用し、低速または CPU バウンドのクエリを分離することができます。数百万もの実行中のクエリを整理し、問題を正確に特定する明確な方法を提供するので、過去のデータを参照することができます。
次の例では、非効率的に一時テーブルを使用しているクエリを見つけました。これを配列変数に置き換えると CPU 使用量が減少します。
CPU 使用率にスパイクを引き起こす非効率なクエリ
PgBouncer 設定の一例 (灰色部分)
私たちの開発環境では、パフォーマンステストと負荷テストを行いましたが、すべてのクライアントについて広範なテストを行うことは不可能でした。各クライアントが同じ機能を持っていても、セットアップと設定が異なるので、引き起こされる問題も異なります。またしても、Performance Insights は、高レベルのパフォーマンスを維持していることを確認し、特定のクエリに問題が発生したときに警告してくれました。これらを早期に特定することで、翌朝仕事を始めるクライアントにとって問題になる前に、夜のうちに生産のアップデートを最適化してリリースする時間ができたのです。
Aurora の書き込みスループットが向上したおかげで、すべての変換がたったの 2 週間で終了しました！
変換プロセスへの興奮が収まった今、私たちは開発環境の改善に目を向けています。PostgreSQL と Docker を組み合わせて、生産スキーマのコピーを含む Docker イメージの作成を自動化する取り組みを進めています。これにより、開発者は最新のコピーをいつでも引き出すことができ、開発環境に当たる前に移行やコード化をローカルで実行することができます。これは Microsoft SQL Server を利用した場合、多くのオーバーヘッドなしでは不可能でした。
もちろん、約 2 年の計画、セットアップ、変換、テスト、再テスト (さらにその後のテストが続くことも) という努力を経て、お祝いの準備が整ったのです。当社は、バーベキューや地元の醸造所から調達したビア樽を提供し、従業員たちと楽しい午後を過ごしました！
New Innovations のマネージメントチーム、バーベキューフードトラックと一緒に変換プロセス中の当社のソフトウェアをテストするのに、何日も何週間も費やしてくれたすべての従業員には本当に感謝しています。会社全体が一丸となりこのような成功プロジェクトを生み出せたことを誇りに思います。
Stephen Sciarini 氏は、New Innovations の IT マネージャーであり、AWS クラウド、その他コンピューティングリソースのセキュリティと戦略計画を担当。 New Innovations の前には、アクロン大学でコンピュータサイエンスコースの非常勤講師を務め、チャリティサイトからオンラインアプリケーションポータルに至るまで数多くのプロジェクトで民間契約者としてとして勤務していました。
Rich Hua は、アマゾン ウェブ サービスの Aurora と RDS for PostgreSQL のビジネス開発マネージャーです。
この記事は New Innovations の IT マネージャー、Stephen Sciarini 氏によるゲスト投稿です。
New Innovations が構築してきたビジネスは、すべてがさらに大きな目的 (質の高い医学教育を提供する権限を医療教育者や管理者に与えること) を示唆する共有されたアイデアや信念に基づいています。インテリジェンスは、タスクとテクノロジーを区別しないところまで進歩しており、その結果、医療研修生や教育者は日常の管理義務から解放されます。医療教育分野のパートナーは当社と協力して、この理想的な未来の実現に取り組んでいます。
その未来はそれほど遠くはありません。AWS と Amazon Aurora PostgreSQL のおかげで、当社は顧客の要求を満たすために拡大したインフラストラクチャを構築することができました。AWS Database Migration Service(AWS DMS) によって、Aurora PostgreSQL への移行は、リスクを最小限に抑えながら、顧客と当社のソフトウェア開発者の両方にとってシームレスな体験となりました。AWS DMS を使用し、Microsoft SQL Server の 700 以上のインスタンスを Aurora PostgreSQL に完全に移行しました。さらに、Amazon RDS Performance Insights によってデータベースレイヤーの優れた可視性が得られるため、あらゆる異常に素早く対応することができます。
会社沿革
1995 年以来、New Innovations は医療研修医データを収集し管理する方法を再考し続けています。私たちは、適格認定を取得し維持するための機能を含む、卒後医学教育 (GME) および学部医療教育 (UME) プログラムが単一システムで必要とするすべてのものを提供します。当社のソフトウェアスイートが管理と実行可能なタスクを簡素化し、教職員とスタッフの手間を省き教育に専念できるよう働きます。学生、居住者、特別研究員の受け入れから、スケジューリングとパフォーマンス分析まで、New Innovations が意のままに管理します。今日、当社のソフトウェアは世界中に広がっており、病院、メディカルスクール、個人開業医において数多くの医療教育分野に貢献しています。私たちの夢は、医療教育が直面する管理上の拘束から解放された世界です。そうなれば医療機関は、いつか私たちの世代がお世話になる介護者の育成に集中することができます。
当初は…
2014 年以前は、当社のインフラストラクチャは地域のデータセンターでホストされていました。しかし、拠点の拡大とともに、より多くのサーバとストレージが必要になりました。データセンター環境で従来のサーバーを使用していた人であれば誰でも、新規サーバーの立ち上げ、設定、ハードニング、データのコピーなどの苦労と面倒なプロセスを理解しています。データセンターへ毎週行き、故障したドライブを交換し、ハードウェアを検査することは珍しくありませんでした。この時点で、当社はクラウドホスティングの検討を始めました。Amazon のコスト、評判、HIPAA / FERPA 認証を考慮すれば、当社プラットフォームのホスト先として選択することに迷いはありませんでした。2014 年の初めに、Microsoft SQL Server データベースと IIS ウェブサーバーをデータセンターから Amazon EC2 に移行し始めました。その年の 4 月までに、全ワークロードを AWS に移行すると、当社のサイトパフォーマンスが 40％ 以上向上したため、コスト削減とパフォーマンス改善をすぐに実現しました。それは計画された 15 分未満のダウンタイムを達成しながら完了しました。移行の容易さを理由に、Amazon S3 のファイルストレージ、AWS Lambda、AWS WAF、Amazon DynamoDB など他の AWS のサービスの利用をすぐに開始しました。
問題
移行後に、当社は SQL Server のインスタンスを超え始めていたことが分かりました。実行するにはコストがかかり、システムのボトルネックになっていました。私たちは SQL Server 2005 を実行していたので、チームはさまざまなオプションの重さを測り始めました。SQL Server 2014 にアップグレードすると、ライセンス使用に年間で何百万ドルもの費用がかかります。その問題を踏まえ、同チームはオープンソースのデータベースサーバーに切り替えることを決断したのです。そのコミュニティや、信頼性、安定性、および必要に応じて有償サポートのオプションがあるという理由で、当社は PostgreSQL を選択しました。続いて、ホスティングの決定です。Amazon RDS や独自の EC2 インスタンスの実行など、いくつかのオプションを試しました (この時点ではまだ Aurora PostgreSQL は発表されていませんでした)。AWS はすでに、Amazon RDS で豊富な PostgreSQL サーバーのフリートを起動するのを容易にしていました。そこで当社はすぐにこれを戦略とし、MSSQL のストアドプロシージャと関数を PL / pgSQL に変換することに目を向けました。
オブジェクトとスキーマの変換
各データベースに約 11,000 個のオブジェクトがあるために、オブジェクトの変換はプロセスの中で圧倒的に困難な部分でした。このプロセスを簡素化するために、関数を変換し、ファイルにコメントを追加して、いかに書き換えが必要であるかを示すツールを作成しました。たとえば、あるストアドプロシージャが “TOP 5” を持っていた場合、この生成されたファイルは関数を変換する人に、 PostgreSQL の “LIMIT” 句に変更するようコメントで示します。どちらかといえば基本的なプログラムでしたが、多くのケースを処理し、数週間分の作業が不要になりました。多くの場合、関数のパラメータタイプによって、PostgreSQL で動作するようにコードを更新する必要がありました。この更新は、単純なウェブ設定の変更で当社のウェブサーバーを PostgreSQL ドライバーと SQL Server ドライバー間で切り替えられるような形で実行されました。
これは数年前のことですが、当社はスキーマを変換する独自のツールを作成することを決定しました。それ以来、お客様にはスキーマ変換プロセスを自動化するのに AWS Schema Conversion Tool (AWS SCT) を広く採用していただいています。
データ変換プロセス
開発者がオブジェクト変換に取り組む一方で、当社の DevOps チームはクライアントのデータベースを変換するために “イージーボタン” を作成しました。当社のプラットフォームでは、データベースレベルごとにそれぞれのクライアントが区別され、クライアント間でデータが混じり合うことはありません。このツールで、必要な事前作業をすべて行い、AWS DMS エンドポイントとタスクを設定して起動し、選択したテーブルでほんの少し手動変換します。完了すると、索引、外部キー、およびトリガーをテーブルに適用し、今後参照するためにログファイルを Amazon S3 にアップロードします。PostgreSQL にはインデックス、外部キー、トリガを無効にする良い方法がないので、最適なスループットを得るために PostgreSQL のドキュメントに従い、すべてのデータをインポートした後にそれらを加えました。そうすることで、変換後のサーバーでの CPU 使用率は高くなりましたが、変換時間の短縮が必要でした。この負荷を管理するため、同時に 4 つのインデックスのみを適用しました。これにより、余った CPU を実行中の他の変換に充てることができました。
クライアントにとってスムーズでシームレスな体験となるように、私たちはクライアントのデータベースごとにこのプロセスを何度も実践しました。”イージーボタン” の一部は、当社の DevOps エンジニアによって作成されたツールで、変換後のデータの検証もしました。これにより、変換されたデータベースの整合性をチェックし、欠落しているレコードがないことを確認することができました。(AWS DMS はデータ検証機能を発表していませんでした。現在ではこの機能を備えています。)
Aurora PostgreSQL への移行
2017年の春、当社は Aurora PostgreSQL ベータ版へのアクセス権を取得し、すぐに RDS for PostgreSQL から Aurora PostgreSQL へ移行する作業を開始しました。Aurora PostgreSQL クラスタをスピンアップし、開発データベースを変換しました。それは書き込みスループットとストレージの自動拡張という、いくつかの非常に重要な改善を伴い、Amazon RDS の完全互換品となったことがわかりました。平均して、Aurora への書き込みスループットの速さは、従来の RDS の約 3 倍でした。変換プロセスはすぐにこの恩恵を受けました。
Aurora のストレージサブシステムは、必要に応じて自動的に拡張されます。Amazon RDS では、将来のストレージニーズを計画する必要があったため、各サーバーに 1 TB のストレージを作成する必要がありました。Aurora では、使用分だけを支払うので、気にすることなく数ヶ月先までスペースを拡張することができます。
AWS が Aurora 用に提供する最も価値あるツールの 1 つが、Performance Insights です。当社の DBA は日常的にこのダッシュボードを使用し、低速または CPU バウンドのクエリを分離することができます。数百万もの実行中のクエリを整理し、問題を正確に特定する明確な方法を提供するので、過去のデータを参照することができます。
次の例では、非効率的に一時テーブルを使用しているクエリを見つけました。これを配列変数に置き換えると CPU 使用量が減少します。
コネクションプーリング
コネクションプーリングについては、pgpool-II もしくは PgBouncer のいずれかを使用できることを知っていました。設定がシンプルなため、PgBouncer を選択しました。Aurora を最適に使用するために、両者間での HAProxy ロードバランシングで、Aurora クラスタごとに 3 つの PgBouncer のインスタンスを備えました。この設定では、クラスタごとに 1 つの PgBouncer インスタンスを読み取り専用インスタンスにすることもできました。冗長性のため、各アベイラビリティーゾーンに複数の PgBouncer インスタンスを使用しました。変換の始まり
2018 年 1 月、クライアントデータベースの変換を開始しました。700 以上のクライアントデータベースそれぞれをゆっくりと変換するのに 1 ヶ月かかることが予定されていました。毎晩、使用パターンに基づいてさまざまなクライアントタイプを適切に組み合わせたグループを変換します。小規模なデータベースから始めて、各サーバーにゆっくりと負荷をかけました。各サーバーは負荷を非常にうまく処理していたので、毎晩変換数を増やしました。私たちの開発環境では、パフォーマンステストと負荷テストを行いましたが、すべてのクライアントについて広範なテストを行うことは不可能でした。各クライアントが同じ機能を持っていても、セットアップと設定が異なるので、引き起こされる問題も異なります。またしても、Performance Insights は、高レベルのパフォーマンスを維持していることを確認し、特定のクエリに問題が発生したときに警告してくれました。これらを早期に特定することで、翌朝仕事を始めるクライアントにとって問題になる前に、夜のうちに生産のアップデートを最適化してリリースする時間ができたのです。
Aurora の書き込みスループットが向上したおかげで、すべての変換がたったの 2 週間で終了しました！
結論
私たちは Amazon Aurora PostgreSQL とその管理のシンプルさに惚れ込んでいます。パフォーマンスを最適化するのに、設定ファイルのチューニングと調整をして対処していた時代は終わりました。この記事では多くを書きませんでしたが、AWS Database Migration Service はデータ移行向けの素晴らしいツールでした。このツールを使用することで、成功プロジェクトを生み出す自動化に注力できたのです。変換プロセスへの興奮が収まった今、私たちは開発環境の改善に目を向けています。PostgreSQL と Docker を組み合わせて、生産スキーマのコピーを含む Docker イメージの作成を自動化する取り組みを進めています。これにより、開発者は最新のコピーをいつでも引き出すことができ、開発環境に当たる前に移行やコード化をローカルで実行することができます。これは Microsoft SQL Server を利用した場合、多くのオーバーヘッドなしでは不可能でした。
もちろん、約 2 年の計画、セットアップ、変換、テスト、再テスト (さらにその後のテストが続くことも) という努力を経て、お祝いの準備が整ったのです。当社は、バーベキューや地元の醸造所から調達したビア樽を提供し、従業員たちと楽しい午後を過ごしました！
著者について
Stephen Sciarini 氏は、New Innovations の IT マネージャーであり、AWS クラウド、その他コンピューティングリソースのセキュリティと戦略計画を担当。 New Innovations の前には、アクロン大学でコンピュータサイエンスコースの非常勤講師を務め、チャリティサイトからオンラインアプリケーションポータルに至るまで数多くのプロジェクトで民間契約者としてとして勤務していました。Rich Hua は、アマゾン ウェブ サービスの Aurora と RDS for PostgreSQL のビジネス開発マネージャーです。
コメント
コメントを投稿