物件検索基盤の一部をAWS DMSに移行する

はじめに

イタンジ株式会社の奈良です。基盤チームの開発エンジニアとしてイタンジの複数のサービスが利用している物件検索基盤の開発と運用をしています。

本記事では物件検索基盤の一部をAWSのマネージドサービスに移行した経緯とその方法について紹介しようと思います。

背景

私が日々開発と運用を担当している物件検索基盤のうち、検索用データの収集、集約と永続化を実現する部分については、AWSのKinesis Data Streamを非同期なメッセージキューとして利用するPub/Subメッセージングモデルを基本としたイベントドリブンなアーキテクチャを採用してます。
このうちイベントを発行する部分(以降Producerと記載)とイベントを処理する部分(以降Consumerと記載)の両方でScalaとAkka Streamを利用したシステムとなっていました。

課題

前述の物件検索基盤はProducerを複数のライブラリを用いて独自実装していたこともあり、技術継承や保守の観点から問題が有りました。 また、イベント量の増加に伴い物件検索基盤のスループットを向上させる必要があったのですが、 順序保証処理をProducer側に追加していたことで性能が向上し辛いという状況もありました。 この様な理由から、物件検索基盤全体の信頼性をこれ以上高めることが難しくなっていました。

解決方法

このProducerを保守していく上での時間的コストや技術的難易度、工数などについて相談した結果、 ProducerをAWSのマネージドサービスであるDMS*1に移行する決断をし、 結果としてこの問題を解消しました。

実際に対応したこと

既存のProducerのコードベースと同様にデータベースの変更イベントを読み取ってKinesisにイベントを発行するDMSタスクを作成し、DMSが発行するイベントの形式に合わせて既存のConsumerに修正を加えながら移行作業を進めていきました。

対応していく中で難しいと感じた部分が幾つか有ったのですが、その中から以下3点を共有していきます。

イベント発行の順序保証

既存のProducerでは安定性に不安が有りましたが、Akka Streamを利用して書かれたリトライ処理などのお陰で発行されるイベントの順序については保証されていました。 AWS DMSではイベントが安定して発行されますが、発行するイベントの順序保証をしないため、イベントの順序保証をConsumer側で行う必要がありました。 この順序保証処理についてはConsumerに実装を追加することで対応しましたが、実装が複雑で非同期なシステムのトランザクション処理の難しさを感じました。

インスタンスとタスク

DMSはEC2の様なインスタンスの中に実際に処理をするタスクを追加する*2ことで上記の様な動作をするのですが、 このインスタンスについてはインスタンスタイプが複数あり、 また1つのインスタンスにタスクを複数追加することが出来る*3ため、 適切なインスタンスとタスクの配分を調整するのが難しかったです。*4

設定の調整

DMSは元来データベースから他のデータベースへの移行を想定して作られているため、 色々な設定項目*5や機能が使用出来ます。 今回DMSへの移行を進める中で突き当たった問題として、ターゲット*6となるKinesisのシャード数を増やしても発行されるイベント数が上手く増加しないというものがありました。 こちらについてはマルチスレッドでの処理を行うためにタスク設定TargetMetadata.ParallelApplyThreadsを、シャード数に合わせて以下の様に変更することで上手くスケール出来る様になりました。

{
    "TargetMetadata": {
        "ParallelApplyThreads": <ターゲットになっているKinesisのシャード数>,
        "ParallelApplyBufferSize": <default: 100>,
        "ParallelApplyQueuesPerThread": <default: 1>
    }
}

メリット・デメリット

メリット

マネージドサービスであるAWS DMSに移行したことで、自前で実装したProducerの技術継承の難しいコードベースの管理や保守に割かなければならない工数の削減に繋がりました。 また、Producerの移行先となるDMSの構成管理をTerraformで出来る様になったことで管理が容易になりました。 そしてこれは既存のProducerに比べてより良くなった部分となりますが、イベントを発行する時刻を指定して流すことや、全データのイベント発行などこれまで運用していたProducerでは実装の変更が必要だった複雑な操作が、画面や構成変更のみで容易に行える様になりました。 この部分が実現出来たことでより弾力性のある物件検索基盤に近付けたのではないかと考えています。

デメリット

既存のProducerはパフォーマンスを重視して非常に短い時間でイベントが発行出来るように実装されており、 これをDMSに移行したことでイベント発行までの処理時間が数100msec程度遅くなりました。 技術検証の過程でこの事象は確認されていて、社内で相談した結果問題無いという判断に至り移行しました。

終わりに

以上が、今回私が物件検索基盤を移行する中で得た知見です。 AWSのマネージドサービスは非常に便利なものも多いのですが、反面膨大な設定項目や機能を使いこなせないこともあるかと思います。 この記事がそういった悩みを解消し開発していく上で手助けになれば幸いです。

*1:Database Migration Service

*2:AWS DMSのコンポーネント

*3:追加するタスクに掛かる負荷次第であるとも言えます。

*4:状況に合わせた調整を行う必要がありそうです。

*5:AWS Database Migration Service タスク設定の指定

*6:AWS DMSが発行するイベントの発行先です。