Amazon Web Services ブログ

OrthoFi社は、Amazon RedshiftとAWS Glueを使って、どのようにお客様に知見を提供したのか

本記事は、OrthoFi社のChrista Pierson氏とJon Fearer氏によって投稿されたものです。

OrthoFi社は、収益管理サイクル(RCM)における歯科矯正業界のリーダーであるとともに、全国で550件を越える歯科矯正診療所と連携し、歯科矯正医が多くの患者を受け入れられ、より効果的に事業が運営できるようなエンドツーエンドのプラットフォームを提供しています。これまで、OrthoFi社は、クライアントが50万人以上の患者に高品質かつ手頃な矯正歯科治療を支援しており、米国で最も急成長している民間企業としてInc.5000リストに3回選ばれました。

この記事では、OrthoFi社が、お客様により良い知見を提供するため、Amazon RedshiftとAWS Glueへどのようにマイグレーションしたのかを、お話していきたいと思います。

 

挑戦

私たちのOrthoFi社は、業界のサービスのリーダーです。しかしながら、私たちのクライアントの多くは、データと分析のためにGaidgeを使っています。特に、私たちのお客様は患者の支払計画や保険金請求のライフサイクル管理のために、私たちのプラットフォームをお使いなのですが、Gaidgeやカスタム分析を使いキャッシュフローや事業の健全性のような全体像を把握するのです。システム間連携がないため、データがサイロ化しており、クライアントの多くが自身のビジネスのパフォーマンスを正確に把握することに苦労していました。

これらの問題を解決するため、私たちは2つのプラットフォームを統合することに決めたのです。1つ目の目標は、ビジネス指標の単一かつ包括的なビューをお客様に提供することでした。これは、歯科矯正診療をより良くするためです。2つ目の目標は、独自のデータレイクやデータウェアハウスを構築するクライアントに対して、内部のビジネスインテリジェンスや将来の統合を支援できるように拡張することでした。過去、データウェアハウス構築を進めたことがあります。ところが、複雑なETL（Extract – 抽出 / Transform – 変換・加工 / Load – ロード）パイプラインの管理やコスト効率良く計算資源を活用するための設定に苦労したのです。これらの経験から、私たちは手頃な価格で成熟しているツールの選択を考えたのでした。

 

ソリューションと意思決定

目の前の課題とカスタム分析に対するニーズを考慮して、既存のETLおよびSnowflakeデータウェアハウスから移行することに決定しました。以下の要求に対応するためです。

  • ビジネスライン（Lines of Business – LOB）アプリケーションからデータウェアハウスへのデータの移行が容易であること
  • データウェアハウスにあるデータの集計が効率よくできること
  • データをインテグレーションパートナーやお客様に提供するためのAPIレイヤーを構築し、同時にセキュリティやパフォーマンスが考慮されていること

データパイプラインのため、KafkaやAmazon Kinesisのようなストリーミングツールではなく、ETLソリューションを採用することにしました。これは、ユースケースにおいて、データが1分毎や1時間毎に定期更新されるものではないからです。例えば、Gaidgeは夜間にデータを取り込むだけです。また、LOBアプリケーションをデータウェアハウスにインテグレーションするのにできるだけ時間を使いたくありませんでした。そのため、ビジネス指標を精度良く計算することやAPIを構築することに、より時間を費やすことにしたのです。既存のETLパイプラインの複雑さに加えて、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの管理と関連するソフトウェアライセンスに課題がありました。最終的な要件は、他のAWSのサービスと密に結合されたツールを使うことでした。弊社においてほぼ全社的にAWSを使っているためです。

これらの各決定事項から、私たちはAWS Glueを使うことにしました。そのため、コード生成とすでに利用しているSQL ServerやAmazon Aurora PostgreSQLなどのOLTPデータベースと、容易に統合することができたのです。AWS Glueもソフトウェアライセンスが不要であり、サーバーレスでした。それは、EC2インスタンスの管理から解放されるということです。

データウェアハウスをサポートする主データベースエンジンを選択する際には、Snowflakeから移行する価値があるかどうか判断する必要がありました。私たちは、運用コストを削減したかっただけでなく、迅速に結果を提供する必要もありました。すでに、AWS Glueを採用することを決めていましたし、APIレイヤーをAWS上で運用したいとも考えていました。そのため、他のAWSのサービスと容易にインテグレーションできるツールを必要としていたのです。Amazon Redshiftの柔軟な価格モデルとAWS GlueやAWS Lambdaとのインテグレーションの容易さを考慮し、（Amazon Redshiftにより）迅速な移行と新しいインテグレーションを両立できると、私たちは判断したのでした。

最終的に、私たちにとって、APIレイヤーの選択はおそらく一番簡単なものになりました。Amazon API GatewayとLambdaはすでに他のプロジェクトで広範囲に使っていましたので、.NET Core APIをLambda上に構築し、インテグレーションパートナーに対してデータを提供することにしました。（Lambdaの）コールドスタートとタイムアウトを回避できるかどうかが、私たちの懸念事項の1つでした。そのため、Provisioned Concurrency を利用しました。将来的に、より大規模なもしくは複雑なデータセットを提供する必要がある場合には、コンテナもしくはAmazon EC2をベースとしたソリューションを代わりに検討することになるでしょう。

 

技術の詳細

ETLパイプラインは、AWS SDKに含まれるETLスクリプトAPIを使ってPythonベースのAWS Glueジョブを全て生成することができました。これにより、従来のカスタムETLの実装と比較して、開発期間を数ヶ月短縮できました。ETLスクリプト（Pythonファイル）とAWS Glueジョブは全てTerraformで管理およびデプロイされます。継続的なレプリケーション機能のために、AWS Database Migration Service (AWS DMS) を利用することを検討しています。レポートの要件は、ほぼリアルタイムではありませんが、継続的なレプリケーションパイプラインを追加することで、数分以内にデータを最新に更新するという将来のニーズを満たすことができるでしょう。

データを集計するために、AWS Glueジョブによってデータがロードされた後に更新されるマテリアライズドビューを採用しました。OrthoFi独自レポートのビジネスロジックの多くは、SQLで記述されてしまっているからです。そのため、このロジックをAmazon Redshiftマテリアライズドビューに移植することは比較的容易なことだと考えました。SQLを変換するツールを利用することはできますが、今回の場合、変更は必要最小限なため手作業で行うことができました。実際の更新コマンドは、Amazon CloudWatchイベントルールによってトリガーされるLambda関数によって実行されます。Gaidgeインテグレーションで常に新しいデータを利用できるようにするために、定期的に更新しました。しかし、将来のユースケースにおいてAmazon Redshiftの自動リフレッシュ機能も使用する予定です。

Amazon Redshiftクラスターのサイズを決定するために、いくつかの異なるサイズを試し、マテリアライズドビューのパフォーマンスとAPIレイヤーのレイテンシーを調査しました。AWS Glue経由でデータをロードし（マテリアライズド）ビューを更新する場合、DC2.Large 6ノードのクラスターサイズであれば必要なパフォーマンスが得られることがわかりました。それ以外の場合は、コスト削減のため3ノードのクラスターサイズを維持します。弾力的なサイズ変更を使用して、2つの構成間でスケールアップとスケールダウンを行います。OrthoFiの自律的成長と追加の分析のニーズにより将来的にデータ量が増加するので、マネージドストレージの利用およびパフォーマンス向上のためRA3ノードタイプを検討するかもしれません。

以前のETLツールからAWS Glueへ移行するなかで、Amazon Redshiftと連携するようにAWS Glueで今までのジョブを再現する必要がありました。AWS Glueを使うことによって、最低限の準備で既存のデータベースからAmazon Redshiftへテーブルとビューを直接レプリケーションできました。これにより、ETL処理が1時間以内に完了するようになりました。次は、Snowflakeで構築したデータウェアハウスをAmazon Redshiftに移行することでした。Amazon RedshiftはAmazon Simple Storage Service (Amazon S3) と非常に簡単に連携できるため、最小限の作業でSnowflakeからAmazon Redshiftへのデータ一括転送を行うことができました。

データ移行に関する我々の戦略は、SnowflakeのCOPYコマンドを使って、最初にデータをS3バケットへコピーすることでした。この直後に、RedshiftのCOPYコマンドを続けます。S3からRedshiftへデータをロードするためです。移行中にデータ損失を防ぐため、ETLツールの特徴的な性質を利用することができました。このプロセスでは、S3連携のために、最初にSnowflakeにおいて ”ストレージインテグレーション” を作成しなければなりません。Redshiftが容易に解釈できる形式でデータを出力する必要があることに注意してください。今回は、最大サイズ1024MBのパイプ区切りのCSV形式で上手く行きました。また、SnowflakeとRedshiftがS3にアクセスするための適切なIAMロールを作成しなければなりません。下記のサンプルスクリプトにて再現可能です。

-- Snowflake
create storage integration <your_storage_integration_name>
type = external_stage
storage_provider = s3
storage_aws_role_arn = '<your_snowflake_iam_role_arn>'
enabled = true
storage_allowed_locations = ('<your_migration_s3_bucket>');

-- Snowflake
copy into <your_migration_s3_bucket>
from <your_source_table>
storage_integration = <your_storage_integration_name>
ENCRYPTION=( TYPE='AWS_SSE_S3' )
FILE_FORMAT= (
TYPE=CSV
COMPRESSION=NONE,
FIELD_DELIMITER='|',
FIELD_OPTIONALLY_ENCLOSED_BY = '"'
NULL_IF=('NULL')
EMPTY_FIELD_AS_NULL=FALSE
)
OVERWRITE=TRUE
HEADER=TRUE
MAX_FILE_SIZE=1024000000;

-- Redshift
copy <your_target_table> (<your_target_columns>)
from '<your_migration_s3_bucket>'
iam_role '<your_redshift_iam_role_arn>'
delimiter AS '|'
NULL AS 'NULL'
timeformat 'YYYY-MM-DD HH:MI:SS'
REMOVEQUOTES
IGNOREHEADER AS 1;

 

下図は、上述したアーキテクチャを反映したものです。

 

結果

Gaidgeのインテグレーションは、ベータ段階です。そのため、新しい指標や機能を頻繁に追加するという作業を繰り返しています。インテグレーションの最初の成功に加えて、AWS Glueのサーバーレスという特徴とAmazon Redshiftに組み込まれている対障害性の機能により、運用のオーバーヘッドが必要最小限になることがわかりました。これらのツールにより、インテグレーションとスケーリングに新しく得られた経験を追加して、より大規模なデータ量をサポートするのは容易でした。私たちは、より多くのクライアントが自身のビジネスのパフォーマンスをより良く理解するために、インテグレーションが可能になることを楽しみにしています。

 

次のステップ

Gaidgeインテグレーションに加えて、独自のデータウェアハウスを構築している一握りの大規模なクライアントに対して、APIを公開しました。これにより、OrthoFiのパワーユーザーは、必要に応じて自身のデータを検索し、集計もしくは自身で選択したツールを使って可視化することができるようになります。将来的に、私たち自身の社内向けおよびユーザー向けの分析を改善することも考えています。当社の目標は、全てのクライアントが自身のデータにアクセスし分析を容易にすることです。AWSのデータと分析サービスを利用することによって、非常に簡単に実現できることがわかりました。

 

原文はこちらです。