Oracle Cloud Hangout Cafe Premium #4 - マイクロサービスとデータマネジメント / microservice-and-datamanagement

Oracle Cloud Hangout Cafe（おちゃかふぇ）のセッションスライドです。

(セッションの録画)
https://youtu.be/mjhBGepIAuk

(イベントページ)
https://ochacafe.connpass.com/

#ochacafe

Transcript

1. OCHaCafe Premium #4 マイクロサービスとデータマネジメント Subhead goes here on one line Shingo Yamanari Oracle Corporation Japan June 30, 2021
2. Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 自己紹介 日本オラクルのプリセールスで製品担当部署に所属 日本オラクル株式会社 クラウド・エンジニアリング統括 ソリューション・アーキテクト本部 プリンシパル・クラウド・ソリューション・エンジニア 山成慎吾 2
3. Agenda 3 2 1 アプリケーション観点から見たのデータソースの考え方 デザインパターンから見たデータストアの考え方 あらためて「マイクロサービス」とは Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 3
4. Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | あらためて「マイクロサービス」とは 4
5. デジタルトランスフォーメーション | 社内業務の効率化から新ビジネスの創造へ ビジネスにもとめられる進化のスピードと品質 ✓サービスの早期リリース ✓市場の動向/反応を早期フィードバックして対応 ✓サービス停止による機会損失をなくす システムは変化するビジネス要件に合わせ 短い時間で高頻度にリリースする事が求められる ✓アプリの変更をすぐに本番環境に適用 ✓変化を許容できるシステムを構築 ✓停止時間の短縮と運用作業の効率化 企業システムに求められるニーズの変化 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 業務 効率化 社外 社内業務の 効率化 社外顧客向け 新ビジネス 創造 5
6. 迅速に高品質なシステムを育て続けるための戦略 マイクロサービスの世界観 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | DevOps • 自動化された高頻度リリース • フィードバックに基づく継続リリース マイクロサービス・アーキテクチャ • 疎結合型アーキテクチャ • サービス単位のデプロイメント サービス単位の組織 • 小規模でサービス毎の自主性・自律性 • 機能横断的なチーム 6
7. DevOpsを視野に入れたマイクロサービス・アーキテクチャに対する期待 マイクロサービス・アーキテクチャ • 大規模なシステムを疎結合な複数のサービスの 組み合わせで実現する設計方式 • 変更による影響範囲をサービス単位に極小化 し高頻度のアプリケーション更新を実現 DevOps • 開発・運用の組織的な隔たりを無くし、サービス の継続的な更新を実現する • CI/CDツールを用いてアプリのテストからデプロイ を自動化し、迅速なリリースと品質確保を両立 高頻度リリースを実現するための開発トレンド Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 計画 開発 ビルド テスト デプロイ 運用 監視 変更 7
8. サービス間の影響を極小化しシステムの変更容易性を高めるアーキテクチャ 保守とテストの容易性 • 分割したサービス毎に組織を編成し開発・運用の自由度を高める • 更新単位を最小限にすることでテスト規模を最小化 疎結合 • API化や非同期化によりサービス間の結合度を低減 • 変更による他の稼働中のサービスにへの影響を極小化 独立してデプロイ可能 • データソースやアプリケーション・モジュールをサービス毎で占有 • デプロイやスケールの変更の単位サービス毎で任意に最適化 マイクロサービス・アーキテクチャとは Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | API サービス実装 データストア イベント・ストア 8
9. 変化に対する影響が伝播しやすい データソースの共有による弊害 • データベースのテーブルをサービス 間で共有 • 一部のサービスでカラムの型変更 • 他のサービスで想定外の動作 リソースの共有による弊害 • 同じアプリケーション・サーバ上に 異なるサービスをデプロイ • 一部のサービスがCPUメモリリ ソースを大量消費 • 他方のサービスで遅延や予期せ ぬエラー 同期呼出し連携による弊害 • 他のサービスを同期呼出し • 呼出し先のサービス内の処理中 にエラー • 呼出し元のサービスも連鎖的に エラー 従来のアーキテクチャが抱える課題 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | アプリケーション・サーバ 製品 カタログ サービス 注文管理 サービス 在庫管理 サービス Error! Error! 更新アクセス 参照アクセス(増大) 製品 カタログ サービス 注文管理 サービス 在庫管理 サービス 製品マスタ 型変更 Error! 誤動作 注文管理 サービス 在庫管理 サービス 注文履歴 Error! 在庫マスタ Error! Error! 9
10. サービス間の影響の伝播を抑止してサービス毎にデプロイメントをコントロール 共有リソースによる依存関係の解消 • サービス毎でランタイムやリソースを占有し • APIを通して疎結合化 • サービス単位で変更やスケールを制御可能 • サービス単位で実装方式の選択可能 非同期連携による影響の伝播の回避 • メッセージング等の基盤で処理を蓄積し非同期化 • 各サービスの任意のタイミングで処理可能 • 停止などによる全体への影響を極小化 マイクロサービス・アーキテクチャの主な強み Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | コンテナ 製品 カタログ サービス コンテナ 製品 カタログ サービス コンテナ 製品 カタログ サービス コンテナ 注文管理 サービス アプリケーション・サーバ 在庫管理 サービス NoSQL RDB キャッシュ 注文管理 サービス 在庫管理 サービス RDB 製品 カタログ サービス 在庫予約チャネル 更新通知チャネル 在庫マスタ 一定のスルー プットで処理 NoSQL REST API 10
11. ① デザインパターンから見たデータストアの考え方 • サービス毎にライフサイクルを制御するための非同期をベースとした連携 • サービス間でやり取りするデータの一貫性をどのように持たせるか？ ② アプリケーションの特性に合わせたデータソースの考え方 • サービス毎に独占・隠蔽されたデータソースを持つべき • サービス実装に合わせたPolyglotなデータ・モデル向けのデータストアの選択肢は？ 本日のお題：マイクロサービス・アプリケーションで利用するデータストアの選び方 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 注文管理 サービス 在庫管理 サービス 在庫マスタ 注文履歴 ① ② ② 11
12. Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | デザインパターンから見たデータストアの考え方 12
13. 基本はサービス毎にデータソースを分割 データソースを他のサービスから隠蔽＆独占 • 他のサービスからは自分のデータソースは見えない (存在自体も隠す) • 自分のデータソースの責任は自分で (データの一貫性、メンテナンス、環境構築、運用、etc.) マイクロサービスにおけるデータソースの考え方 在庫管理 サービス 注文管理 サービス Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 13
14. Event Sourcingパターン：データアクセスをイベントで相手のサービスに連携 呼出し側のサービスのイベントをイベント・ストアを経由して連携する方式 • 「注文管理サービス」側の処理 • 「注文」や「キャンセル」などを処理の単位でイベント・ストアに送る • 在庫の修正を待たずに「注文」や「キャンセル」などのリクエストを受け付けて完了させる • 「在庫管理サービス」側の処理 • 「注文」や「キャンセル」等のイベントを適宜受け取って順番に在庫マスタを更新する 基本となる非同期のデータ管理パターン Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 注文管理 サービス 在庫管理 サービス 在庫マスタ API 注文 在庫修正 注文 キャンセル Event Sourcing パターン イベント・ストア 14
15. Event Sourcingパターン：何が嬉しいか？ 呼び出される側のサービスを任意のタイミングで止められる • ユーザからの「注文」は受付完了できる • イベント・ストアに格納さえできれば「注文管理」の処理が完了できる • 在庫管理のサービスは、復旧してから順次在庫処理を実施するだけでよい 基本となる非同期のデータ管理パターン Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 注文管理 サービス 在庫管理 サービス 在庫マスタ API 注文 在庫修正 Event Sourcing パターン イベント・ストア 注文 キャンセル メンテナンス中 15
16. コンシューマ側の障害ケース 「取り出す」 → 「処理を行う」 → 「消費する」 の間で 落ちてしまった場合 • 「消費する」が確定するまでにアプリケーションが 落ちると容易にメッセージが重複 • イベント・ストアとサービス側のデータ・ソース間で 不整合が生じる Event Sourcingの障害ケースの例 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 在庫管理 サービス 在庫マスタ 1. 取り出す 在庫管理 サービス 在庫マスタ 2. 在庫を減らす 在庫管理 サービス 在庫マスタ 同じ処理が重複 5. 復旧 在庫は減った状態 在庫管理 サービス 在庫マスタ 3. 落ちる 4. 取り出してなかったことになる 在庫は減った状態 ※ “Handling duplicate messages using the Idempotent consumer pattern” https://chrisrichardson.net/post/microservices/patterns/2020/10/16/idempotent-consumer.html Idempotent Consumer Pattern (※) 16
17. メッセージにキーを付けてコンシューマ側で重複排除 Idempotent Consumer Pattern の大まかな仕組み 1. プロデューサ側でメッセージにキー(=Idempotency Key)を付与する 2. コンシューマ側でサービスの処理と同じトランザクションでIdempotency Keyをキーにした処理履歴を残す 3. 処理履歴にある重複メッセージは処理済みとして無視する 処理と処理履歴の一貫性を維持する手法 • ローカル・トランザクションでビジネス・エンティティと履歴テーブルを更新する (リレーショナルの場合) • ビジネス・エンティティにIdempotency Keyを保持して更新する (NoSQL等の場合) Idempotent Consumer Pattern Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 在庫管理 サービス 在庫マスタ 処理履歴 2. 在庫を減らす 2. 履歴を残す (Key=XX) 1. 取り出す (Key=XX) 同一トランザクションで処理 17
18. XAトランザクションを利用した一貫性の担保 X/Open XA • X/Open社による分散トランザクションの標準規格 • 2フェーズ・コミットをベースとした一貫性担保のしくみ 2フェーズ・コミットの仕組み • 更新対象のデータを排他ロック • 更新可能かどうかを事前にチェック • 全員更新可能であれば一斉に更新、一人でもNGな ら全員ロールバック 参考) 従来のデータソース間の一貫性の担保のしくみ Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 正常時の動作 障害時の動作 リソース・ マネージャ OK OK トランザクション・ マネージャ OK NG リソース・ マネージャ トランザクション・ マネージャ 広範囲の排他ロックが原因で性能ボトルネック になりやすい (スケールしない) 18
19. スケーラビリティと重複排除の難易度を踏まえた判断 マイクロサービス間の連携におけるイベント・ストアの考え方 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | トポロジのバリエーションや重複排除のシンプルさから at least once が現実的 • XAによる性能ボトルネック • 並列処理前提の 1 対 多 トポロジ、など QoS 主な利用トポロジと特徴 Exactly once 必ず1回、重複無し、ロスト無し • 1 対 1 のトポロジ • XA前提の一貫性が一般的 • スケーラビリティが限定的 At least once 必ず1回以上、重複あり、ロスト無し • 1 対 1、または 1 対 多のトポロジ • Idempotency Consumerによる重複排除 • スケーラビリティが高い At most once 多くとも1回、重複無し、ロストあり • 1 対多、多対多のトポロジ (ブロードキャスト型) • サービス間連携では論外 • スケーラビリティが高い 19
20. Oracle Cloud Infrastructureで提供されるイベント・ハブ型のマネージドサービス OCI Streaming Service (ストリーミング) Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | ▪ ユースケース ログやイベント、Web/MobileやIoTからのデータストリームを集約、 マイクロサービス間で発生する大量のイベント・メッセージを確実に伝達 ▪ 特徴 複雑になりやすいサービス間やコンポーネント間の接続経路を、Streamingを経 由する形にすることでシンプルにすることが可能 Pub/Subモデルの採用により、データ通信を非同期に行い急激なデータ増加によ るシステム負荷の上昇を抑制 Streamingに接続するためのAPIやSDKを提供 • 専用SDKとKafka互換APIを提供 ▪ 価格 データ転送(登録/取得)1GBごとに¥3 データの保持1GB×時間ごとに¥0.024 ▪ 関連するOracle Cloud Service • Events (イベント・サービス) • Oracle Functions (ファンクション) • API Gateway IoT Mobile/Web Activities App Kafka Client Streaming Streaming Events API Gateway Database System Object Storage Functions 20
21. OCI Streamingを利用したEvent Sourcing の実装例 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 注文管理 サービス 在庫管理 サービス 在庫マスタ 処理履歴 API 注文 在庫修正 注文 キャンセル Streaming Autonomous Database Functions API Gateway Container Engine For Kubernetes ② Idempotency Key + 注文 をイベントとして送信 No SQL Database ① 注文情報を取得 ③ Idempotency Key で重複確認 ④ Idempotency Key と在庫更新を同時処理 21
22. OCI Streamingを利用したEvent Sourcing のデモ Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | order -func Inventory -app 在庫マスタ 処理履歴 API 注文 在庫修正 注文 キャンセル Streaming Autonomous Database Functions API Gateway ② Idempotency Key + 注文 をイベントとして送信 No SQL Database ① 注文情報を取得 ③ Idempotency Key で重複確認 ④ Idempotency Key と在庫更新を同時処理 Virtual Machine 22
23. 大まかな処理の流れ：重複排除を行う正常ケース Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | Order Function Order Consumer Order Provider handleRequest() consumeMessages() order() putMessages() getRow() ack() ここでConsumeが確定 同じトランザクション order -func Inventory -app inventory idempotency commit() UPDATE inventory INSERT INTO idempotency begin() 23
24. 実装に関わる主なSDKや標準仕様など Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | Order Function Order Consumer Order Provider handleRequest() consumeMessages() order() putMessages() getRow() commit() ack() OCI SDK (NoSQL) 同じトランザクション order -func Inventory -app OCI SDK (Streaming) MicroProfile Reactive Messaging CDI extension for Oracle UCP begin() inventory idempotency UPDATE inventory INSERT INTO idempotency 24
25. Consumeすべきメッセージが残ってしまうケース 障害ケース：コミット直後に inventory-appが落ちた場合 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | Order Function Order Consumer Order Provider handleRequest() consumeMessages() order() putMessages() getRow() Consumeされないまま残る order -func Inventory -app Idempotencyと在庫処理は完了 エラーで落ちる (強引に例外発生) commit() begin() inventory idempotency UPDATE inventory INSERT INTO idempotency 25
26. 重複排除を判断して更新処理をスキップしてConsume 障害ケースからの復旧の流れ Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | Order Function Order Consumer Order Provider handleRequest() consumeMessages() order() putMessages() getRow() ack() Consume漏れのイベントをConsume 重複のイベントのため一意制約 違反として更新処理をロールバック order -func Inventory -app rollback() begin() inventory idempotency UPDATE inventory INSERT INTO idempotency 26
27. Consumeできなかったイベントを重複処理してしまう 重複排除をしない場合の障害後の流れ Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | Order Function Order Consumer Order Provider handleRequest() consumeMessages() order() putMessages() getRow() order -func Inventory -app 同じイベントを再度更新してしまう ack() Consume漏れのイベントをConsume commit() begin() inventory UPDATE inventory 27
28. イベント通知によりサービス間を連携する方式 呼び出される側のサービスが、呼出し側のサービスのイベント・チャネルをサブスクライブ Sagaパターン Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 注文管理 サービス 在庫管理 サービス 在庫マスタ API 注文 在庫修正 注文 キャンセル イベント・チャネル イベント・チャネル 在庫あり 在庫無し 注文マスタ 注文確定 28
29. イベント・チャネルをイベント・ストアで代用する例 リクエスト/レスポンスの双方向のやりとりをEvent Sourcingで行う • イベント・ストアがイベントを永続化 • 相手のサービスが停止していても自分のサービスは処理を完了できる Event Sourcingを応用したSagaパターン Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 注文管理 サービス 在庫管理 サービス 在庫マスタ API 注文 在庫修正 注文 キャンセル イベント・ストア イベント・ストア 在庫あり 在庫無し 注文マスタ 注文確定 29
30. 障害時などにビジネス・トランザクションとして回復する 何らかの障害で処理を完了できない場合に、処理を取り消して整合性を合わせる。 例：注文マスタの更新に失敗 → 在庫修正を元に戻してもらう (＝注文のキャンセルを発行) 複数個所での障害など、補償トランザクションの設計が煩雑になりやすい。。。 → 長いトランザクションは控えるのがbetter Sagaパターンの補償トランザクション Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 注文管理 サービス 在庫管理 サービス 在庫マスタ API 注文 在庫戻し 注文 キャンセル イベント・ストア イベント・ストア 在庫あり 在庫無し 注文マスタ 注文確定 先ほどの注文は キャンセルで！ 注文はキャンセル なので在庫を戻す 30
31. Choreography-based Saga と Orchestration-based Saga Choreography-based Saga • 呼出し元のイベントにしか興味を持たない • 全体のトランザクションに無責任になりがち • いくらでも連鎖できてしまいトランザクションが長くなる Orchestration-based Saga • 呼出し元を呼出し先が管理する • ネスト型の構造になり責任分界点を明確にできる • 呼出し元が呼出し相手の結果などのステートを管理す る必要がある → ステート管理のためのストアが必要 2つのSagaパターン Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | Service A Service B Service C Service D Service E Service A Service B Service C Service D Service E B の処理状態 C の処理状態 D の処理状態 E の処理状態 31
32. REST APIベースの補償トランザクションの仕組み 連携するサービス間で、処理状態を判別して補償処理を調停するフレームワーク • LRA (＝複数のサービスによる一連の処理) 内の1つのサービスが失敗すると、他のサービスの補償処理を呼び出す • JAX-RSで呼び出されるメソッドにアノテーションを付与して調停が必要な処理をマーク • LRAの開始/終了/参加/離脱、補償処理、正常終了、etc. • LRAのコンテキストIDがHTTPヘッダで伝播される 参考：MicroProfile LRA (Long Running Action) Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | Eclipse MicroProfile LRA 1.0-M1 (Draft) https://download.eclipse.org/microprofile/microprofile-lra-1.0-M1/microprofile-lra-spec.html @Path("/") @ApplicationScoped public class SimpleLRAParticipant { @LRA(LRA.Type.REQUIRES_NEW) @Path("/cdi") @PUT public void doInTransaction(@HeaderParam(LRA_HTTP_CONTEXT_HEADER) URI lraId) {...} @Complete @Path("/complete") @PUT public Response completeWork(@HeaderParam(LRA_HTTP_CONTEXT_HEADER) URI lraId, String data) {...} @Compensate @Path("/compensate") @PUT public Response compensateWork(@HeaderParam(LRA_HTTP_CONTEXT_HEADER) URI lraId, String data) {...} } 呼び出されるとLRAが開始される LRAが完了すると呼び出される(リソースのクリーンアップなどに使う) LRAがキャンセルされるとと呼び出される (補償処理に使う) 成功 失敗 キャンセル (補償処理) LRAコンテキスト LRAコンテキスト 32
33. イベント・ストアとサービス毎のデータ・ストアの組み合わせ 非同期でサービス連携する際の一貫性の考え方 • サービス間のメッセージをロストしない＆重複させない仕組みが必須 • スケーラビリティ＆ 1 対 多通信を踏まえ、at least onceでコンシューマ側で重複排除するのが合理的 • 多段で構成される非同期連携は一貫性の保証が煩雑 (ご利用は計画的に！) • Oracle Cloud Infrastructure上で利用するならマネージドのStreamingサービス 非同期連携で必要となるサービス用のデータ・ストア • 重複排除用のIdempotencyキー・ストアが必要 • サービス内の更新処理と同じトランザクションで一貫性を担保 • Orchestration-based Sagaなど、サービス間の処理状態を保持するストアが必要になるケース デザインパターンから見たデータストアの考え方 (まとめ) Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 33
34. Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | アプリケーション観点から見たデータソースの考え方 34
35. ① デザインパターンから見たデータストアの考え方 • サービス毎にライフサイクルを制御するための非同期をベースとした連携 • サービス間でやり取りするデータの一貫性をどのように持たせるか？ ② アプリケーションの特性に合わせたデータソースの考え方 • サービス毎に独占・隠蔽されたデータソースを持つべき • サービス実装に合わせたPolyglotなデータ・モデル向けのデータストアの選択肢は？ 本日のお題：マイクロサービス・アプリケーションで利用するデータストアの選び方 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 注文管理 サービス 在庫管理 サービス 在庫マスタ 注文履歴 ① ② ② 35
36. 基本はサービス毎にデータソースを分割 データソースを他のサービスから隠蔽＆独占 • 他のサービスからは自分のデータソースは見えない → 自由に選択できる • Agilityを重視してアプリケーションにとって扱いやすいデータモデルをベースにしたストアを選ぶ マイクロサービスにおけるデータソースの考え方 在庫管理 サービス 注文管理 サービス Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 在庫マスタ 在庫参照用キャッシュ 外部に見えないからこそ、 扱いやすいものを選ぼう！ 36
37. モノリシックな業務アプリケーションで選択してきたデータソース 「リレーショナル・データベースありき」になっていなかったか？ • 「リレーショナル・データベース」を選択する理由 • データ処理の一貫性 • データの一意性 (主キー、グループに対する一意性制約) • 正規化による冗長性排除 • SQLによる検索の利便性 過去を振り返ってみて Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 例えば、注文が確定していないショッピング・カートのアイテム • 正規化されている必要性は？ • ユーザあたり 10+件程度のアイテムを検索する必要性は？ 何のためにO/R マッピングやって るんだっけ。。。 37
38. アプリケーション・プログラムから利用する視点で 【リレーショナル型 (通称SQL/RDB)】 • データ間の関係に厳密(一貫性、制約、など) • オブジェクトとの対応付けにO/Rマッピングが必要 【ドキュメント型】 • 階層構造に従ったデータへのアクセス • オブジェクトの構造を表現しやすい (JSONなど) 【Key Value型】 • 基本的にはValueに対する検索や、部分的な更新をしない(get/putのみ) • オブジェクトをそのままKeyやValueと対応付けて利用する 【グラフ型/空間データ型、etc.】 • 特殊な関係の検索に重きを置く • データ分析に利用されることが多い (ソーシャルグラフ、ヒートマップ、etc.) 主要なデータ・モデルとその特徴 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 38
39. 優先すべき要件に合わせたデータソースの選択 それぞれのサービスの特徴を踏まえたデータ・モデルの選択 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 在庫管理 サービス 注文管理 サービス カート 注文マスタ 商品メタデータ 在庫マスタ 配送管理 サービス 配送履歴マスタ 配送実績データ 顧客IDをキーにと商品IDのコレクション が追加削除可能なドキュメント型 商品ごとに型の異なるスキーマレス が扱えるドキュメント型 配送経路の関係を表現できる グラフ型と空間型 複数データへの更新が発生す る一貫性が重要なマスタ情報 のためのリレーショナル型 39
40. Autonomous Database Autonomous JSON Database MySQL Database Service NoSQL Database Cloud Service リレーショナル型 〇 △ (※2) 〇 ドキュメント型 (JSON) 〇 〇 〇 〇 Key Value型 〇 (※1) △ (※1, 2) 〇 (※1) 〇 グラフ型 〇 △ (※2) 空間型 〇 △ (※2) 〇 マネージド・サービス別の利用可能データ・モデル Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | ※1. KeyとValueのみのテーブルとして構成 ※2. 20GB以下の領域のみ非JSON領域として利用可能 40
41. できるだけ簡単かつ手早くREST化、JSON化を サービス間のやり取りの仕組みの中心となるのは REST API & JSON Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 在庫管理 サービス 注文管理 サービス カート 注文マスタ 商品メタデータ 在庫マスタ API JSON フロント・エンド用API 非同期連携 のイベント 商品管理 サービス 商品マスタ JSON JSON サービス間のAPI連携 41
42. Autonomous Database Autonomous JSON Database MySQL Database Service NoSQL Database Cloud Service リレーショナル型 の操作 SQL SQL SQL ドキュメント型 の操作 API / SQL API / SQL API / SQL API / SQL JSONへの マッピング JSON関数 JSON関数 JSON関数 REST APIの作成 〇 〇 マネージド・・データベース・サービス別のREST/JSON化の機能 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 42
43. 完全メンテナンス・フリーな自律型ハイパフォーマンス・マネージド・データベース Oracle Autonomous Database Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 柔軟性 オンラインのままスケールアップ・ダウン／自動スケール CPU停止による課金停止も可能（Storageは課金継続） 可搬性 100%オンプレミス版との互換性 既存資産・既存スキルをそのまま活用可能 運用管理性 Oracle オペレーションによるエラー監視、パッチ適用 機械学習による障害予知および事前対策 開発生産性 細かな設定やサイジングは不要／最小限の入力項目に て作成後わずか数分で利用可能に 自動最適化 リアルタイム監視、分析、検証 を通じて、 機械学習による性能の自律的向上 パフォーマンス データベース基盤にExadataを採用、IOボトルネックをハードウェ ア・ソフトウェア両面から排除 可用性 フラッシュバック技術や多重化構成、Maximum Availability Architectureによる99.95%SLA セキュリティ パッチ適用の自動化、機械学習による 外部攻撃の検知と防御、多段階のアクセス制御 43
44. Converged Database による “Polyglot Persistence” への対応 ▪ 活用シーン マイクロサービス毎の用途に合わせてデータ・タイプを柔軟に選択 マネージド・サービスを活用しアプリケーション開発・運用に専念 ▪ 特徴 リレーショナルのみではなくNoSQLやグラフ、位置情報など、多種多様なデー タ・タイプをシングル・インスタンスで利用 利用するデータ・タイプに依らず、プロビジョニングやアクセスなど同一の手法で 利用可能 可用性・セキュリティなどのインフラストラクチャ管理はマネージドサービスとして 一元管理 利用目的に応じてオンラインでのスケール変更に加え、利用状況に応じた自 動スケーリングにも対応 ストアド・プロシージャはもちろんのこと、ORDSによるREST APIの作成や SODA APIでのNoSQLアクセスなど、データにまつわる開発機能を凝縮 Autonomous Databaseで活用可能な多彩なデータ・タイプ Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | JSON Graph Key Value NoSQL Relational Spatial Files Oracle Autonomous Database 44
45. ドキュメント型データに特化したマネージド・サービス JSONをベースとした開発のための新サービス • Autonomous Databaseで稼働するJSONストレージ • SODA APIによるシンプルなドキュメント・アクセス • SODA = Simple Oracle Data Access • 各種言語・ドライバに対応 • 非JSON領域として20GBまで利用可能 NoSQL ドキュメントストアと同様のベネフィットを提供 • 柔軟性が高く、迅速にスケール（Compute/Storage） • Read / Write時の低レイテンシ • 高性能、可用性、セキュリティ、柔軟性 Autonomous JSON Database Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | SQL REST 45
46. JSONでアクセスするアプリケーション & JSONに対するSQLベースの分析 API と SQL 両方の操作モデルをサポート Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | JSON Oracle Database / Exadataを使用した JSONドキュメントの保存と管理 JSONに対するSQLベースの レポート作成と分析操作 SQL Autonomous JSON Database SODA APIを使用して 開発されたアプリケーション 46
47. JSONでアクセスするアプリケーション & JSONに対するSQLベースの分析 NoSQL と SQL 両方の操作モデルをサポート Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | JSON Oracle Database / Exadataを使用した JSONドキュメントの保存と管理 JSONに対するSQLベースの レポート作成と分析操作 SQL Autonomous JSON Database SODA APIを使用して 開発されたアプリケーション 47
48. SODAの特徴と概念 SODA API • ドキュメント・アクセスに特化したAPI • Java, C, Python, Node.js, PL/SQL及びRESTに対応 SODAの基本的な用語 • SODAデータベース • アクセス対象のデータベース • SODAコレクション • ドキュメントを格納するコレクション • 実体はJSONを格納可能な表 • SODAドキュメント • 格納するJSONなどのドキュメント • 内部的なキーやタイムスタンプ等も持つ SODA (Simple Oracle Document Access) Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | ドキュメント ドキュメント ドキュメント Cart コレクション ドキュメント ドキュメント ドキュメント Favorite コレクション ドキュメント ドキュメント ドキュメント Profile コレクション Autonomous JSON Database 48
49. とてもシンプル！ 様々な言語に対応したSODA API Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | Java OracleClient client = new OracleRDBMSClient(); db = client.getDatabase(jdbcConn); OracleCollection col = db.admin.createCollection("purchase_orders"); col.admin().drop(); Node.js conn = await oracledb.getConnection(…); db = conn.getSodaDatabase(); col = await db.createCollection("purchase_orders"); await col.drop(); PL/SQL (and Oracle Application Express) col := dbms_soda.create_collection('purchase_orders'); select dbms_soda.drop_collection('purchase_orders') from dual; Python conn =cx_Oracle.connect(…); db = conn.getSodaDatabase(); col = db.createCollection("purchase_orders"); col.drop(); 49
50. Node.jsでSODAを使ってドキュメントを格納する ドキュメントを追加/取得する際のおおまかな流れ • Oracle ClientでDBに接続 • SODAコレクションを取得する • SODAコレクションにJSONを格納する • 同時にキーを取得 • キーを使ってSODAドキュメントを取得する • SODAドキュメントのコンテンツ (=JSON) を取得する SODAを使ったプログラミングのイメージ Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | ※参考: Example: Simple Oracle Document Access (SODA) in Node.js http://oracle.github.io/node-oracledb/doc/api.html#examplesodaawait データベースを使っている 感じがしない、直観的！ 50
51. Oracle Database のデータをREST化してアクセス Oracle REST Data Services (ORDS) Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | Oracle Database上のデータに対するRESTアクセスをクイックに作成 • Java EEアプリケーションサーバ上で動作するもWebモジュール • Oracle WebLogic Server, Apache Tomcatに対応 • 開発用のスタンドアロン・モードも提供 • URIをSQLやPL/SQLにマッピング • 問い合わせの結果をJSONやCSVで取得 • OAuth 2.0 に対応 Oracle Database Application Server ORDS モジュール SQLドライバ HTTP GET/POST/PUT/DELETE http://dbhost/ords/tiger/emp/7844 application/json JSON 51
52. ORDSはマネージド環境としてデフォルトで提供 Autonomous DatabaseでのORDSの利用について Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | APEX環境の構成要素としてデフォルトでORDSも構成済み • APEX WorkspaceからUIベースで構成可能 • Lowの事前定義済みデータベース・サービスを使用 • 外部向けなど接続数の多い用途に利用する場合は、別 途外部のAPサーバを立てる構成を推奨 • Database Actionや、PC上からSQL Developerを利 用した開発も可能 52
53. サービス・モジュール • 複数のORDSテンプレートのグループ • アクティベートの単位 ORDSテンプレート • URIパスに対応するREST APIの定義 • REST APIのリソースの各URIと1対1で対応 リソース・ハンドラ • HTTPメソッド毎に定義される処理ハンドラ • SQLクエリやPL/SQLをハンドラとして選択 • ハンドラ毎にパラメータのバインディングを行う ORDSでREST APIを定義する際の主な構成要素 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | サービス・モジュール ORDSテンプレート リソース・ハンドラ 53
54. アプリケーションからの利用を考慮した場合の作成パターン AutoREST • 表構造のままのアクセスに適用 • スキーマ・オブジェクトをそのまま REST化 • 表や行をそのままの形で自動的に JSONに変換してレスポンス • Design Firstなアプリケーション用 のAPIには不向き SQL リソース・ハンドラ • SQL 1文で書ける処理に適用 • リクエストURIの値をSQLの引数に バインディング • リクエスト・ボディにアクセス不可 • JSON関数を使用してレスポンス のJSONを生成 • GET向け PL/SQL リソース・ハンドラ • 複数のSQLによる処理に適用 • リクエストURIの値をプロシージャの INにバインディング • リクエスト・ボディにアクセス可能 • プロシージャのOUTの一覧からレ スポンスのJSONを自動生成 • PUT/POST/DELETE向け ORDSによるREST APIの作成パターン Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | { "empno":7844, "ename":"TURNER", "job":"SALESMAN", "mgr":7698, "hiredate":"1981-09-08T00:00:00Z", "sal":1500, "comm":0, "deptno":30 } { "employeeId":7844, "employeeName":"TURNER", "position": { "job":"SALESMAN", "manager":7698 } } { “status":“success", "employeeId":7844 } レスポンスのJSONの例 レスポンスのJSONの例 レスポンスのJSONの例 54
55. EMP表のデータをJSONの階層構造に変換 SQLリソース・ハンドラを利用したJSONボディの生成例 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | MGR EMPNO ENAME JOB HIREDATE SAL COMM DEPTNO employeeNumber name profile job hireDate salary EMP表 変換後のJSONの構造 SELECT 'application/json', json_object( 'employeeNumber' VALUE e.empno, 'name' VALUE e.ename, 'profile' VALUE json_object( 'job' VALUE e.job, 'hireDate' VALUE e.hiredate, 'salary' VALUE e.sal ) ) FROM emp e WHERE e.empno = :empno 設定するSQLリソース・ハンドラ https://adbhostname/ords/demo01/hr/json/sample/:empno ORDSテンプレートのURI 55
56. 誰が使うAPIか？ どのような呼出し方をするAPIか？ Design FirstなAPIの考え方 マイクロサービス Database メインフレーム ERP, Applications iPaaS/SOA/Service Bus (既存システムへの接続性) API Gateway 汎用 (IT) APIs iPaaS （データ変換/フォーマット変換） 公開/固有 (Business) APIs API Gateway Web & モバイル アプリ コミュニティ 顧客、3rd Party 開発パートナー SaaS パートナー SaaS IdM ディレクトリ Reliable Agile Bimodal IT IT IT / Partners ID管理 認証 認可 SSO Federation Microservices APIs Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 56
57. フルマネージド＆低コストなMySQL Enterprise Edition OSSデータベース筆頭のMySQLをフルマネージドで提供 • MySQL Databaseと完全互換 • Enterprise Editionの機能も包含 • Enterprise Audit/TDE/Firewall, etc. • 3タイプのデプロイメント • シンプルなスタンドアロン構成 • 自動フェイルオーバー可能な高可用性構成 • OLTP/OLAPの混合ワークロード向けのHeatWave構成 • 圧倒的なコスト・パフォーマンス • ¥6.672 / hour から始められる低価格設定 (1 OCPU/8GB の場合) • ストレージは ¥240 / month から (50GB の場合) • 高性能なOracle Cloud Infrastructureとの相乗効果 MySQL Database Service Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | OLTP Engine Analytics Engine MySQL Database Service MySQL Database Service (Secondary) (Secondary) (Primary) AD1 Paxos AD2 AD3 高可用性構成 HeatWave 構成 57
58. MySQL上でのJSONデータ・アクセス MySQLの標準機能で提供される機能 • もちろんMySQL Database Serviceでも利用可能 • SQL及びX DevAPIベースでアクセス可能 MySQLドキュメントストアの特徴 • リレーショナル・データとJSONを同時に扱える • テーブル内にJSON型のカラムを持つ形式 • X DevAPIによる幅広い言語のサポート • Java, JavaScript/Node.js, Python, C++ • APIによるPartial Updateにも対応 MySQL ドキュメントストア Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 58
59. X DevAPI for Node.js を利用したサンプル・コード collection = mysqlx.getSession({ user: 'myname' }) .createSchema('mySchema') .createCollection('myCollection'); collection.add([{ name: 'foo', age: 42 }]) .execute(); collection.modify('age = :value') .bind('value’, 42) .set('name', 'bar') .execute() collection.find() .fields('name', 'age') .execute() MySQL ドキュメントストアに対する X DevAPIの利用例 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | セッションの作成からコレクションの作成まで コレクションへのドキュメントの追加 条件にマッチするドキュメントの部分更新 指定したフィールドのみの抽出 59
60. MySQL Technology Cafe #13 Oracle MySQL Operator for k8s プレビューリリース版解説 2021年8月12日（木）19:00-21:00 **Connpass 近日公開** MySQLの開発チームが開発しているOracle MySQL Operator for k8sの プレビューリリース版がGitHubで公開されています。 今回のMySQL Technology Cafeでは、Oracleが開発しているMySQL Operatorに ついて機能やデモをご紹介予定です！ Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 60
61. アプリケーション・フレンドリなデータ・モデルに最適なマネージド・データストア フルマネージドで提供される従量課金型のNoSQLデータベース • 扱いの容易なカラムナー型、キーバリュー型、ドキュメント型のデータ・モデ ルを利用可能 • 最新のSSD＋機械学習により実現される、高パフォーマンス＆高信頼性 のフルマネージドNoSQLデータベース・サービス • ハッシュ・ベースの分散アルゴリズムにより、データ量やトラフィックに依存し ない安定した低レイテンシ • テーブル単位でプロビジョニングされ、容量やリクエストベースによる課金 APIとSQL双方に対応した容易なデータアクセス • スキーマベース(KVS)、スキーマレス(JSON)双方に対するAPI/SQLアクセ スに対応 • SQLベースのPartial Updateや、Map型のAPIによるカラムアクセス Oracle NoSQL Database Cloud Service Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | NoSQL Tables Billing NoSQL Database Cloud Service App App App App 61
62. 安定した低レイテンシや非構造データ中心のトランザクション Oracle NoSQL Database Cloud Service のユースケース Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | カタログデータ IoT ユーザー プロファイル管理 モバイル アプリケーション コンテンツ管理 リアルタイム ビッグデータ ソーシャル ネットワーク ゲーム オンライン広告 サーバレス アプリケーション 62
63. Oracle Cloud Infrastructure SDKを利用したJavaのサンプル・コード Oracle NoSQL Database Cloud ServiceのAPIの利用例 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | final ResourcePrincipalAuthenticationDetailsProvider provider = ResourcePrincipalAuthenticationDetailsProvider.builder().build(); final NosqlClient nosqlClient = new NosqlClient(provider); nosqlClient.setRegion(Region.fromRegionId("us-phoenix-1")); List<String> keyList = new ArrayList<String>(); keyList.add("id:id0000"); GetRowRequest getRowRequest = GetRowRequest.builder() .key(keyList) .tableNameOrId("MyTable") .compartmentId(compartmentId) .build(); GetRowResponse getRowResponse = nosqlClient.getRow(getRowRequest); if (getRowResponse != null) { String name = getRowResponse.getRow().getValue().get("name”).toString(); } リソース・プリンシパルを使用した認証 取得するドキュメントのキーを指定 行(ドキュメント)取得リクエストの生成 カラム名を指定したドキュメントの取得 63
64. 課金メトリックとスケール方式を含めた対比表 マネージド・データベース・サービス別対比表 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | ※1. 1 WU は 「1KB のデータを 1 tps」 で書き込みアクセスを予約する単位 ※2. 1 RU は 「1KB のデータを 1 tps」 で読み込みアクセスを予約する単位 Autonomous Database Autonomous JSON Database MySQL Database Service NoSQL Database Cloud Service リレーショナル型 〇 △ 〇 ドキュメント型 (JSON) 〇 〇 〇 〇 Key Value型 〇 △ 〇 〇 グラフ型 〇 △ 空間型 〇 △ 〇 リレーショナル型の操作 SQL SQL SQL ドキュメント型の操作 API / SQL API / SQL API / SQL API / SQL JSONへのマッピング JSON関数 JSON関数 JSON関数 REST APIの作成 〇 〇 処理量に対する課金 ¥161.292 OCPU/hour ¥38.712 OCPU/hour ¥4.560 OCPU/hour ¥15.048 WU/month (※1) ¥0.768 RU/month (※2) メモリ容量に対する課金 ー ー ¥0.264 GB/hour ー データ容量に対する課金 ¥14,208 TB/month ¥14,208 TB/month ¥4.80 GB/month ¥7.92 GB/month 主な特徴 汎用性、自動スケール、 ハイ・パフォーマンス 汎用性、自動スケール、 ハイ・パフォーマンス 汎用性、 コスト・パフォーマンス 低レイテンシ、 スループット課金 64
65. どのような領域に向いている？ Autonomous Database • オールマイティに扱えるマルチ・データモデル。サービス内で複数のデータ・モデルを扱う用途向け。 • ハイ・パフォーマンス、高レベルなセキュリティやオート・スケールが求められる領域向け Autonomous JSON Database • JSONをベースとした用途、及び少量のリレーショナル・データと組み合わせる(またはどちらかの)用途向け。 • ハイ・パフォーマンス、高レベルなセキュリティやオートスケールが求められる領域向け MySQL Database Service • マルチ・データモデルに対応。 サービス内で複数のデータ・モデルを扱う場合向け。 • 動的なスケール変更が不要で、コスト重視のサービス向け。 NoSQL Database Cloud Service • KVSやJSONなどのリレーショナルではないデータ・モデル。エンティティ単位でのデータ参照/更新の用途向け。 • フロントエンドや外部公開APIなど、アクセス頻度が高く安定した低レイテンシが重視されるサービス向け。 マネージド・データベース・サービス毎の使いどころ Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 65
66. 優先すべき要件に合わせたデータソースの選択 それぞれのサービスの特徴を踏まえたデータ・ストアの選択例 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 在庫管理 サービス 注文管理 サービス カート 注文マスタ 商品メタデータ 在庫マスタ 配送管理 サービス 配送履歴マスタ 配送実績データ • INSERT/DELETEをのみの処理 • 季節性に依存した大量トラフィック • 複数のデータモデルの更新管理 • 季節性に依存したトラフィック • 複数のデータモデルに基づく分析 • 大量データに対する分析性能を重視 Autonomous Data Warehouse Autonomous Transaction Processing No SQL Database MySQL Database Service Autonomous JSON Database 商品検索 サービス 商品検索情報 • 商品ごとに異なるデータモデル • 負荷に応じたスケールと一貫性 • CDNなどにキャッシュされるデータ • 大量データを低コストでホスト 在庫履歴マスタ 66
67. アプリケーションが扱うデータ・モデルに焦点を当てた選択 • 「リレーショナルありき」という固定観念を捨てる → 正規化して利用する明確な用途があるかどうか • アプリケーションからのアクセスのしやすさを踏まえてAgilityを損なわないように • Polyglotなデータ・モデルを扱う場合、マルチ・モデル対応のデータ・ストアも検討 サービス間の受け渡しを考えたデータ操作の考慮 • REST APIやそれに準じたデータ・フォーマットでの受け渡し → JSON化が必須 • REST API化の機能は “Design First” なAPIに合っているかを考慮 • JSONで渡されたデータを扱いやすい仕組みを選択する • APIベースでの開発やSQL/JSON関数等でのデータ・ストア側での操作 トラフィックや処理の特性を踏まえたマネージド・サービスの選択 • 優先度の高い要件(性能、可用性、コスト、etc.) と処理の特性を照らし合わせて選択 アプリケーション観点から見たデータ・ストアの考え方 (まとめ) Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 67
68. ① デザインパターンから見たデータストアの考え方 • サービス毎にライフサイクルを制御するための非同期をベースとした連携 • サービス間でやり取りするデータの一貫性をどのように持たせるか？ ② アプリケーションの特性に合わせたデータソースの考え方 • サービス毎に独占・隠蔽されたデータソースを持つべき • サービス実装に合わせたPolyglotなデータ・モデル向けのデータストアの選択肢は？ 振り返り：マイクロサービス・アプリケーションで利用するデータストアの選び方 Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 注文管理 サービス 在庫管理 サービス 在庫マスタ 注文履歴 ① ② ② • イベント・ストアを活用して重複排除を前提に • 非同期トランザクションはできるだけ短く • マルチ・データモデルの必要性 • サービス間のやり取りはJSON化が中心 • 非機能要件と処理特性、課金メトリックを考慮 68
69. Thank you Copyright © 2021 Oracle and/or its affiliates. All rights reserved. | 69