大量データ_大規模トラザクションをクラウド移行したマイクロサービスでさばく_.pdf

Copyright © 2011-2024 UL Systems, Inc. All rights reserved. Proprietary
& Confidential 0 大量データ・大規模トラザクションをクラウド移行したマイクロサービスでさばく！～MicroProfileで切り拓け～

& Confidential 1 自己紹介 ◼吉橋博満 (よしはしひろみつ) ◼1989年12月4日生まれ ◼福岡県出身 ◼ウルシステムズ株式会社 2020年入社 ◼普段の活動 ‐ Javaを用いたWebアプリ開発、アーキテクチャ検証 ◼好きな技術 ‐ MicroProfile/SpringBoot/GoogleCloud ◼十八番 ‐ Functional Interface

& Confidential 2 話すこと・話さないこと ◼対象の方 ‐ これからマイクロサービスを始める方 ‐ クラウドシフトに取り組もうとされている方 ◼話すこと ‐ エンタープライズなマイクロサービス構築についての取り組み ‐ MicroProfileの良いところ ◼話さないこと ‐ マイクロサービスの一般的な説明 ‐ MicroProfileの詳細な説明

& Confidential 3 アジェンダ ◼プロジェクト概要 ◼前半：マイクロサービス構築への取り組み ‐ マイクロサービスの切り出し ‐ マイクロサービスのインターフェース ◼後半：大量データをマイクロサービスでさばく ‐ 高負荷時の新規DBエラー対応 ◼まとめ

& Confidential 4 今回の舞台は？ ◼ 日本有数のクレジットカード会社 ◼ キャッシュレス普及率は右肩上がり！クレカ利用が加速 ◼ 近年クレジット決済の利用数は増え、データ量も莫大に！！ここ10年で約3倍に！我が国のキャッシュレス決済額及び比率の推移（2023年）経済産業省より

& Confidential 5 どんなプロジェクトなのか？ ◼顧客情報サービスのHybridCloud化プロジェクト ‐ マイクロサービス化による開発生産性向上、スケーラビリティ確保 ‐ サービスごとの適材適所なデータベースの活用 ‐ クラウドへシフトして、今以上の拡張性と可用性を手に入れたい ‐ コンテナ化によるポータビリティの確保オンプレミス FrontEnd App BackEnd App クラウド BackEnd 新規 API 新規 ColumnDB Txテーブルを移行現行のBackendApp から切り出しコンテナで管理 RDB このデータが爆増

& Confidential 6 マイクロサービス化のために採用したのは、MicroProfile！ Javaエンタープライズ開発におけるマイクロサービス向けの仕様と標準を提供するプロジェクト目的：マイクロサービスアーキテクチャ向けに軽量で高性能なJavaアプリケーションの開発を支援基盤：Java EE をベースにした仕様で、マイクロサービス開発に必要な機能を提供

& Confidential 7 なぜMicroProfileなのか？ ◼マイクロサービスに必要な機能が一式提供されている ◼現行AppはJavaEEでできているので、既存技術者を移行しやすい ◼マルチベンダーによる商用サポートが魅力

& Confidential 8 新規クラウドDBへ移行するテーブルの対象 ◼クラウド移行するテーブルの対象について考えていたこと ◼今回は、数十億レコードを持つトランザクションテーブルを対象に決定！データ量が多いテーブルを移行して良い成功体験が欲しいオンプレRDBは複数サービスが参照してる… Readのみのテーブルなら影響少なく移行できる何百ものテーブルを全部移行は難しいから絞る

& Confidential 9 前半：マイクロサービス構築への取り組み～現行からの脱却～

& Confidential 10 マイクロサービスへの切り出し～第壱の壁～

& Confidential 11 モノリスなBackEndAppから、どのように新規APIを切り出すか？ ◼現行のビジネスロジックでは、移行対象/対象外のテーブルに同時アクセス現行 BackEndApp ビジネスロジックテーブルA テーブルB テーブルC 移行対象（Readのみ）他サービスへの影響などの前提から、テーブルの移行対象を広げるのは難しいテーブルを移行する対象を変えずに現行のビジネスロジックを切り出せるか？ RDB Writeあり, 対象外

& Confidential 12 まずはビジネスロジックごと切り出す検討！ ◼ビジネスロジックを新規APIに移植。新規DBと現行RDBにアクセス ◼フロントエンドから新規APIを呼び出して、ビジネスロジックを実行 BackEnd 新規 API テーブルA テーブルB ビジネスロジック A Read B Read テーブルC C Write FrontEnd App BackEnd 現行 App RDB 新規 ColumnDB

& Confidential 13 クラウドクラウドクラウドシフト時の要考慮事項 BackEnd 新規 API 新規 ColumnDB オンプレ RDB 直接アクセス禁止オンプレミス FrontEnd App BackEnd 現行 App RDB BackEnd 新規 API 新規 ColumnDB ２回またぎたくない新規API⇒オンプレRDBへの直接アクセス禁止 (セキュリティ要件) オンプレ⇒クラウド⇒オンプレの往復はしたくない (NWレイテンシ)

& Confidential 14 CRUD処理のみを切り出すことに決定！ ◼現行のビジネスロジックは移植せず、CRUD処理のみ切り出す ◼新規DB、移行対象のテーブルにのみアクセス BackEnd 現行 App ビジネスロジックテーブルA テーブルB テーブルC A Read B Read C Read/Write BackEnd 新規 API テーブルA テーブルB A Read B Read 切り出し RDB 新規 ColumnDB

& Confidential 15 Dのコンテキスト Cのコンテキスト CRUD処理を切り出すのはアンチパターンだが…？ ◼境界付けられたコンテキストで分割し、ロジックとDBを切り出すのが王道 ◼異なるコンテキストに存在するテーブルだから、この部分を切り出したテーブルA テーブルB テーブルB テーブルA テーブルC テーブルD コンテキストの境界 AとBのコンテキスト

& Confidential 16 最終的なマイクロサービス構成！！オンプレミス FrontEnd App BackEnd 現行 App ビジネスロジックテーブルA テーブルB テーブルC A Read B Read C Read/Write オンプレミス FrontEnd App BackEnd 現行 App ビジネスロジックテーブルC C Read/Write クラウド BackEnd 新規 API テーブルA テーブルB A Read B Read RDB RDB 新規 ColumnDB Before After 新規 APIを介して取得オンプレの経路を維持

& Confidential 17 第壱の壁、クリア！ ◼移行対象のテーブルを広げずに、マイクロサービスを構築 ◼今回の移行対象は異なるコンテキストにあるからCRUDのみを切り出した ◼NWレイテンシやセキュリティ要件も考慮して、新規APIの呼び出しを検討できた

& Confidential 18 マイクロサービスのインターフェース～第弐の壁～

& Confidential 19 現行のフロントエンド-バックエンドApp間通信を確認 ◼フロントエンドとバックエンド、それぞれのロジックで使うDTOが個別にある ◼通信するときに、お互いのDTOを送信しあっている現行AppのインターフェースはDTOによる依存度が強い新規APIのインターフェースはDTOによる依存度を減らせないか？ FrontEndApp BackEndApp B F B F フロントDTO バックDTO

& Confidential 20 App間で異なるDTOを使ってインターフェースを作ると困ることプロパティの名前が違うと変換を間違えるしデータ型が違うと変換ミスが起きるフロントエンド DTO バックエンド DTO 区分A 区分1 区分B 区分2 名前が微妙に違うフロントエンド DTO バックエンド DTO String int int Integer 数字を文字で表現 Nullを許容お互いのモジュールに、お互いが使うDTOのライブラリが依存 FrontEndApp BackEndApp フロント DTOライブラリバックエンド DTOライブラリフロント DTOライブラリバックエンド DTOライブラリバックエンドのロジックで使うものフロントエンドのロジックで使うもの

& Confidential 21 MicroProfile OpenAPIなら、スキーマ駆動開発をして解決できる！ ◼OpenAPI に準拠 ◼アノテーションを付けるだけで利用可能 ◼今回は実装としてPayara Microを利用ココが使える！

& Confidential 22 OpenAPIは、REST APIをスキーマで記述する言語仕様

& Confidential 24 Microprofile OpenAPIをサンプルで説明 ◼ エンドポイントにアノテーションを付けたコードと、生成されたスキーマの一部サンプル @GET @Path(“person/list") @Produces(MediaType.APPLICATION_JSON) @Operation( operationId = "findByName", summary = "人物情報を検索", description = "クエリパラメータで人物情報を検索" ) @Parameter( name = "name", required = true ) @APIResponse( responseCode = "200", description = "成功" ) List<Person> findByName(@QueryParam("name") String name) { return "hello" } person/list: get: operationId: findByName summary: 人物情報を検索 description: クエリパラメータで人物情報を検索 parameters: - in: query name: name required: true schma: type: string response: '200': description: 成功 content: application/json: schema: items: $ref: '#/components/schemas/Person' type: array

& Confidential 25 Microprofile OpenAPIをサンプルで説明 ◼ レスポンスクラスにアノテーションを付けたコードと、生成されたスキーマの一部 @Schema(description = "人物情報") public class Person { @Schema( description = "ID", minimum = "0", maximum = "9999999" ) private Long id; @Schema( description = "名前", requierd = true, minLength = 1, maxLength = 10 ) private String name; } components: schemas: Person: type: object description: 人物情報 properties: id: description: ID format: int64 maximum: 9999999 minimum: 0 type: integer name: description: 名前 maxLength: 10 minLength: 1 type: string サンプル

& Confidential 26 コードファースト？スキーマファースト？ ◼ コードファースト ‐ OpenAPIの学習ハードルが下がる ‐ サーバ側が出来上がらないとクライアント側の開発に着手できない ◼ スキーマファースト ‐ クライアント・サーバで並行開発ができる ‐ OpenAPIの学習コストが必要になる https://blog.bytebytego.com/p/api-design

& Confidential 27 今回はコードファーストを採用して、新規APIを開発！ ◼先に新規APIを開発して、スキーマを自動生成 ◼新規DBに接続確認を早期に行いたかったスキーマ（OpenAPI） BackEnd 新規 API 新規 ColumnDB MicroProfile OpenAPIで自動生成出来上がり次第新規DBへの接続確認ができる

& Confidential 28 サーバ側コードを実装して、早々にスキーマを自動生成できた ◼デプロイしてアクセスすれば、ブラウザにスキーマが表示される ◼インターフェースに関係する部分さえ実装できていれば、自動生成できる BackEnd 新規 API テーブルA Read テーブルB Read エンドポイントリクエスト/レスポンスデプロイアクセス http://localhost:8080/openapi この部分で自動生成スキーマ（OpenAPI）

& Confidential 29 クライアント側コードを自動生成、開発生産性向上 ◼Generatorを使ってクライアントコードを生成、現行Appにコピペ ◼生成したコードはスキーマを元にしてるので、ライブラリ依存は無くなる入力自動生成 BackEnd 現行 App コピペテストコードも生成スキーマ（OpenAPI）

& Confidential 30 今後の開発はどうするの？ ◼自動生成コードを修正するのは、ツールを使ったメリットが無くなるのでNG ◼インターフェースに修正が発生したら、スキーマファーストで改修！スキーマ（OpenAPI）修正自動生成 BackEnd 現行 App コピペ直接修正はNG クライアントサーバ BackEnd 新規 API スキーマに合わせて修正

& Confidential 31 第弐の壁、クリア！ ◼DTOやクライアントコードを自動生成して、スキーマ駆動開発で依存度を下げることができた ◼以降はスキーマファーストで開発できるので、新規APIを修正する際はクライアント側も並行開発できるようになった

& Confidential 32 前半、取り組んだことから言いたいことエンタープライズなシステムは… 大規模、複雑になりがち時間が経過すればどんどん負債は積み上がっていくだから、普段から課題感を持って取り組むべき！

& Confidential 33 後半：大量データをマイクロサービスでさばく～エラーとの戦い～

& Confidential 34 高負荷時の新規DBエラー対応～最後の壁～

& Confidential 35 大量データ、大規模トランザクションをさばく ◼さばくためには、性能要件を満たす必要がある ◼３つの変数が期待値を満たすことができれば、さばくことができたと判断エラー無く、安定して処理を行うことエラー回数(率) 要求された時間内で処理を行うことレスポンス時間アクセス数の増加に耐えられることリクエスト数

& Confidential 36 新規のDBってどんなもの？ ◼クラウド上のフルマネージドなカラムDB ◼数十億件のレコードを持つトランザクションテーブルを移行 ◼オンライン・バッチともに現行よりも性能が劣化しなければOK 新規 ColumnDB エンドポイントエンドポイントリージョン１リージョン２クラウド BackEnd 新規 API BackEnd 新規 API バッチ処理オンプレミス Read Read Read /Write バッチ処理からはデータの書き込みあり

& Confidential 37 負荷テスト実施時にエラーが？！ ◼新規DBに対して、オンライン処理・バッチ処理を同時実行 ◼オンライン処理はエラー。バッチ処理が異常終了新規 ColumnDB エンドポイントエンドポイントリージョン１リージョン２クラウド BackEnd 新規 API BackEnd 新規 API バッチ処理オンプレミス Read Read 異常終了エラーエラー 12,000 リクエスト/秒が Rate Limit 数億件/月 Insert

& Confidential 38 Rate Limit超過に対する対応案 DB側の設定で、Rate Limitの上限を上げる ⇒ お金がかかるからいったん保留バッチ側のリクエスト回数を減らす ⇒ 採用！リクエスト件/秒 Rate Limit 12,000 件/秒時間オンライン処理のみでRate Limitは発生しないバッチ処理は集中アクセスするから、 Rate Limitが起きる

& Confidential 39 新規 ColumnDB バッチのリクエストを減らして、Rate Limitは解消 ◼ トランザクションデータは、重複したKeyを持つレコードがたくさんあった ◼ 同じKeyのレコードをまとめて１回のリクエストにする。リクエスト回数が減り、Rate Limit解消 Before バッチ処理入力ファイル Key1 Key2 Key3 … … A B D … … A C E … … After バッチ処理入力ファイル新規 ColumnDB A B D … … C E … … リクエスト数減

& Confidential 40 Rate Limitは解決したけど、新たな問題 ◼DBへのリクエスト数が増えたら、レスポンスが遅延する ◼レスポンス時間が上振れしたときにタイムアウトすることがあるレスポンス時間リクエスト件/秒 Rate Limit 12,000 件/秒 DBタイムアウト 0.5秒本番相当リクエスト件/秒

& Confidential 41 タイムアウトを解決する選択肢タイムアウト値を多めに設定する ⇒ 結局微妙だから不採用！オンライン側の処理をリトライさせる ⇒ 採用！新規 ColumnDB BackEnd 新規 API タイムアウト 5000ms ×2 = 10秒??? ユーザーへの目標レスポンス時間 →数秒平均レイテンシ 1000ms 最大レイテンシ 5000ms

& Confidential 42 Microprofile FaultTolerance タイムアウト、リトライを説明 ◼ @Timeoutでタイムアウト時間を設定 ◼ @Retryアノテーションで処理のリトライ回数を設定できる ‐ 最大リトライ回数、リトライ間隔を設定することが可能 ‐ リトライ間隔に乱数を付与して処理の成功率を高めることも可能 ◼ リトライ処理をメソッド単位で設定でき、処理ごとにメリハリを付けられるサンプル @Timeout(500) @Retry(maxRetries = 3, delay = 1000) public String helloRetry() { return "hello" }

& Confidential 43 負荷テストでエラーは無事に解消！ ◼バッチは異常終了せず、エラー回数も減少 ◼オンラインもエラー回数が減少、レスポンス遅延もなし新規 ColumnDB エンドポイントエンドポイントリージョン１リージョン２クラウド BackEnd 新規 API BackEnd 新規 API バッチ処理オンプレミス Read Read エラー減エラー減エラー減リクエスト回数を減らす

& Confidential 44 オンプレミスクラウドクラウド移行したマイクロサービスで、大量データをさばくことができた ◼現行Appからの新規APIへのリクエスト→レスポンスまではミリ秒単位 ◼現行同様に、エラーもなく安定してレスポンスを返却→レジリエンスが強化新規 ColumnDB BackEnd 現行 App BackEnd 新規 API この部分のレスポンスはミリ秒単位 DBからのレスポンスが遅延してもリトライで安定して処理

& Confidential 45 まとめ

& Confidential 46 まとめ ◼CRUD API によるマイクロサービス化 ‐ ビジネスロジックのアクセスするテーブルごと切り出せないなら手始めにマイクロサービスをCRUD処理だけでもいいからやってみるのはアリ ◼OpenAPI による疎結合化 ‐ 現行のアプリケーションでインターフェースが密結合を起こしているなら OpenAPIで疎結合にできるし、スキーマ開発を導入できる ◼レジリエンスの強化 ‐ エンタープライズなシステムだとDBはRate Limitやレスポンス遅延に悩みがちエラーを少なく、安定させるためには、リトライ処理が有効

& Confidential 47 最後に… どんなに試行錯誤しても、答えはだいたい… シンプル

大量データ_大規模トラザクションをクラウド移行したマイクロサービスでさばく_.pdf

大量データ_大規模トラザクションをクラウド移行したマイクロサービスでさばく_.pdf

Other Decks in Technology

Featured

Transcript