PostgreSQLプラットフォームの徹底比較（コンテナからクラウドまで）

2020/11/13のPostgreSQL Conference Japan 2020、チュートリアルセッション用のスライドです。

Transcript

1. PostgreSQLの プラットフォーム徹底比較！ ～ クラウドからコンテナまで ～ PostgreSQL Conference Japan 2020 , 11/13 Takahiro, Kobayashi ( @tzkb)
2. 2 最近やっていること • PGConf.Asia 2019 “Building PostgreSQL as a Service with Kubernetes” • July Tech Festa 2020 “マイクロサービスの今こそ！ 理解して拡げる分散システムの基礎知識” ＋ ＝∞
3. 3 1. あなたのDBはどこに？ 2. まずはここから、RDS for PostgreSQL 3. そしてAuroraの世界へ 4. PostgreSQL on Kubernetesという選択肢 5. ちょっと変わった マネージド の世界 アジェンダ
4. 4 あなたのDBはどこに？ 1
5. 5 PostgreSQLプラットフォームを整理してみると • 現在はオンプレミスからクラウド(マネージドサービス含む)、 コンテナまで様々な環境でPostgreSQLが稼働する。 ベアメタル EC2 ホスト コンテナ ランタイム オーケスト レーション IaaS マネージドサービス (DBaaS) Kubernetes Service オンプレミス Kubernetes EKS Amazon Aurora Amazon RDS 本日の対象
6. 6 ポスグレのプラットフォームは？ @PostgreSQLアンカンファレンス 2020 • オンプレが健在（回答者に若干の偏りあり）。 • VMベースが多いけど、ベアメタルとクラウド同数ぐらい？ • サービス別ではAmazon RDSが抜けているが、Auroraも多い。
7. 7 マネージドなデータベースを使うのはなぜ？ （建前） • ベストプラクティスでしょ？ • 構築もらっくらく。 • 運用もほぼ自動。 （本音） • インストールとか面倒。 • 開発が本業。DBAいない。 • おれたちは雰囲気でDBやってる。 DB
8. 8  パブリッククラウドで PostgreSQLを使う際の選択肢、 どれぐらい知っていますか。  RDS、Auroraなど各サービスの特徴を理解しましょう。  昨今のクラウド上ではコンテナ、 Kubernetesを前提と したサービスも出てきています。  それらの仕組みは理解して、これからのビジネスに最適な PostgreSQLプラットフォームを一緒に考えましょう。 本日のゴール
9. 9 まずはここから、RDS for PostgreSQL 2
10. 10 (今更ですが) Amazon RDS for PostgreSQLとは • AWSが運用してくれる PostgreSQL。 • コミュニティで開発されているピュアPostgreSQLで、これまで 自身のサーバにインストールしていたものと、同じものが使える （但し一部の拡張は使えない）。 • インフラ構築不要、インストールも不要で使い始められる。 • バックアップ・リストアも簡単。 • Multi-AZで高可用性を担保、リードレプリカも構築できる。 • 各種メトリクスもAWSコンソールから確認可能。
11. 11 RDS for PostgreSQLがもたらす効果 電源、ラック サーバ管理 OSインストール OSパッチ DBインストール DBパッチ バックアップ/リストア HA スケール アプリケーション 電源、ラック サーバ管理 OSインストール OSパッチ DBインストール DBパッチ バックアップ/リストア HA スケール アプリケーション オンプレミス Amazon RDS ユーザ による管理 による管理
12. 12 RDS for PostgreSQLで制限されること 制限事項（例） 具体的な例 バージョン選択 現在の最新は12.4（13はBeta）、但し利用可能Verは多数。 リソース上限 r5.24xl(96vCPU、768GBメモリ)、ストレージは最大64TB リソース下限 t3.mic(2vCPU、1GBメモリ) 一部パラメータが変更不可 full_page_writesなど一部のパラメータは変更できない Extensionが限られる pg_hint_planなど一部はインストール可、全てではない。 OSログインできない ssh接続によるOSログインはできない。 • 通常のPostgreSQLと比較すると下記のような制限がある。
13. 13 どんな時に使うのか？ RDS for PostgreSQL • 使わない理由がない。 • AWSでPostgreSQLを使うなら、 特定バージョンや特殊なエクステンションが必要な時を除き、 いつでも。 • これまでの運用・チューニングスキルがそのまま活かせるのも ポイント。  例：Autovacuum関連のパラメータ設定等は基本的に流用可能で、 ワークロードに最適されたPostgreSQLを利用できる。
14. 14 そしてAuroraの世界へ 3
15. 15 Amazon Auroraとは • クラウド向けに構築された、PostgreSQL互換のDBMS。 • つまり、ピュアなPostgreSQLではない。 • 商用DBと同等のパフォーマンスと可用性を1/10のコストで実現 することを目標としている。 • Multi-AZよりも高い3-AZの可用性を実現。 • 高い性能(PostgreSQL互換では3倍とも)と拡張性。 • エンタープライズのニーズに応える各種サービスを展開。  Aurora Serverless  Global Database  マルチマスタークラスタ
16. 16 Auroraのコンセプト 「THE LOG IS THE DATABASE.」 Compute SQL Transactions Caching • ComputeとStorageにDBを分離。ログをStorageに送信する。 • 3つのAZに展開した分散ストレージ にデータを格納する形式。 ※実際は6つのコピー • Compute側からはログを送信し、 それらの永続化(タイミング含め)は ストレージに一任される。 • レプリカノードへのデータ更新は キャッシュ同期で行う。 Compute SQL Transactions Caching Storage Logging Storage Logging Storage Logging P R
17. 17 Amazon Aurora PostgreSQL Compatibleで制限されること 制限事項（例） 具体的な例 バージョン選択 現在の最新は11.8互換のVer3.3、選択可能Verは少ない リソース上限 r5.24xl(96vCPU、768GBメモリ)、ストレージは最大128TB リソース下限 t3.med(2vCPU、4GBメモリ) 一部パラメータが変更不可 checkpointなどアーキテクチャが異なり、それらは利用不可 Extensionが限られる pg_hint_planなど一部はインストール可、全てではない。 I/O料金の存在 データ保持量(GB単位)とI/O料金(リクエスト辺り)の課金 • RDS以上にAuroraでは制約も大きい。
18. 18 たくさんのAuroraファミリー Auroraの各種サービス 特徴 Aurora PostgreSQL 互換エディション 3つのAZに跨る6つのレプリカを保持し、高い可用性を持つ。 AWSに最適化された構成で約3倍と言われる高い性能。 ※他と区別するために、Aurora Provisioned Clusterとも。 Aurora Serverless アプリケーションのワークロードに応じて、DBクラスタを自動的 に起動・停止し、スケールアップ/ダウンを行う。 Global Database 複数のAWSリージョンに跨ってレプリカを構築可能。リージョン 障害時には切り替えることでDR対応ができる。 マルチマスタークラスタ 2つのプライマリインスタンスを構成可能、ダウンタイムをより短 縮できる。 ※PostgreSQLでは未対応 • 一言でAuroraといっても、、、使い分けられますか？
19. 19 Amazon Aurora Serverlessとは Compute Storage Storage Storage • リクエストベースでインスタンスを起動、無風時は停止も可能。 • つまり、ゼロスケールが可能なDBクラスタと言える。 Request Router VPC Endpoints NLB • オンデマンドにCompute(インスタンス) は起動され、利用していない時は 停止される。 • 停止時はストレージ料金のみ。 • 基本的には特定AZのComputeが スケールアップ/ダウンする。 • 障害時は別AZでComputeを起動 するが、FO時間は未定義。
20. 20 Aurora Serverlessの注意点 • 柔軟性は理想的にも見えるが、通常のAuroraとは大きく異なる。 • AWSでは次のようなユースケースを想定。  利用頻度が少なく、不定期なワークロード  負荷が予測できないワークロード  開発やテスト環境として • PostgreSQLバージョンは、10.7のみ。 • 通常のAuroraで使える拡張・AWSサービスも使えない。  postgres_fdw  Performance Insightなど そもそもAuroraを使うべき？
21. 21 Amazon Aurora Global Databaseとは R P R • Region(地域)を跨いで、Auroraのレプリケーションが可能。 • Region障害があった際に、もう一方でサービスを継続できる。 Primary Region Secondary Region • DBMSレベルではなく、 ストレージレベルのレ プリケーション。 • レプリケーションのレ イテンシは低く保たれ、 通常1分以内でFOが 可能とされている。
22. 22 どんな時に使うのか？ Amazon Aurora • より高い可用性、性能を求める時（＞コスト）。 • Oracle(そしてExadata)などの商用の高性能・高可用性DBからの 移植に向いている。 • Oracle Data Guard等のソリューションを使っていた場合にも。 • ピュアPostgreSQLでない点には注意。 • 「クエリ実行計画の管理」など、Aurora独自機能の理解や使い方 を理解する必要あり。 • 運用やコストの考え方で、Aurora固有の考慮ポイントが出てくる ため、それらに習熟する必要がある。
23. 23 PostgreSQL on Kubernetesという選択肢 4
24. 24 PostgreSQL on Kubernetesとは • コンテナ向けプラットフォーム(オーケストレータ)である、 Kubernetes上でPostgreSQLを稼働させる構成。 • (コンテナイメージがあれば) どのバージョンのPostgreSQLも 利用できる。拡張も自由に組込み可能。 • IaCとの相性が良く、宣言的にPostgreSQLの実行できます。 • お手持ちのKubernetesで（ ）、すぐにお試し可能です。 え、Kubernetesって？？
25. 25 PostgreSQL on Kubernetesが出来ること 電源、ラック サーバ管理 OSインストール OSパッチ DBインストール DBパッチ バックアップ/リストア HA スケール アプリケーション on K8sクラスタ による管理 バージョン選択 任意のバージョンを選べる リソース上限 Nodeのキャパシティ次第 リソース下限 CPUはmill core単位で指定可 パラメータ 全て変更可能 Extension 全て導入可能 OSログイン 可能（任意のユーザ作成も可）
26. 26 マネージドPostgreSQLと比較して • マネージドは便利だが、全工程で最適とは限らない。 特徴 • 開発者向け • 1人で1DBが理想 • ユーザ/内部テスト • リリース確認用 • 本番サービス用 マネージド 向き？ • No. • スキーマも辛いが1人 1インスタンスも辛い • Yes. • インスタンスが増え ていくことも。 • Yes. • 可用性も担保できる 開発環境 テスト/ステージング 本番環境
27. 27 例えば、開発環境では • DB作成をオンデマンドに、開発者自身が行える。 apiVersion: v1 kind: Pod metadata: name: postgres-tzkb spec: containers: - name: postgres12-1 image: postgres:12.1 resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1000m memory: 1024Mi volumeMounts: - name: pg-vol mountPath: /var/lib/postgresql/data
28. 28 テスト環境も柔軟に拡張できる Kubernetesの仕組みを使って、 アプリケーションとDBのデプ ロイメントをまとめて、宣言的 に行える。 (DB利用で頻出の専門用語) • StatefulSet（sts） – 安定的なストレージ利用、一 意なホスト名などデータベー スでの利用に向いている。 • Persistent Volume（PV） – PV/PVC/StorageClassを用い て、データを永続化。 AP AP AP 連結テスト ユーザ確認 PV AP AP AP PVC PVC PVC PVC PV PV PV
29. 29 本番環境では、Operatorがベストプラクティス operator pgcluster pgbackups pgreplicas S3等にバックアップが可能 AZ-a AZ-b AZ-c • 左図はCrunchy Dataの PostgreSQL Operatorの概要。 • Streaming Replicationの構成 を自動的に行う。 • 高可用性を備えたクラスタが 深い知識無しで構築可能。 • AWS上で適切な設計を行えば、 Multi-AZ対応も可能。 • バックアップなども実行可能、 DBAの負荷を軽減できる。 R P R
30. 30 PostgreSQL Operatorの例 • Crunchy Data以外にもPostgreSQL Operatorが存在。 開発元 Operatorの特徴 Crunchy Data 早くからPostgreSQLのKubernetes対応を打ち出し、Operatorも順調に進化 している。PostgreSQLコミュニティでの存在感も強く、関連エコシステムと の統合(pgAdmin、pgBackRest等)も得意。 Zalando Kubernetesを早くから商用サービスで運用しており、実績が豊富。Operator も同社で大規模に利用されており、2年以上の運用実績を持つ。Kubernetes コミュニティでの発言力も高い。 EDB PostgreSQLの機能強化版 EDB Postgresを提供、更にそれをKubernetes上 で稼働させるEDB Kubernetes Operatorが開発されている。利用実績は海外 を含めて、まだ多いとは言えない模様。 KubeDB AppCodeが開発しているマルチDBMSなOperator。ただし、最近の開発 スピードに疑問が残る（止まっている？）。
31. 31 どんな時に使うのか？ PostgreSQL on Kubernetes • アプリケーションをKubernetesで動かしている時。 • マネージドサービスより柔軟なリソース配分を行いたい時。 • マイクロサービスと組み合わせるケース。大量に乱立する インスタンスの管理コストを下げる可能性を秘めている。 • 開発・テスト環境でのコンテナDB利用は加速すると思われる。 • なお、Kubernetes自体の管理はDBに限らず、大きな課題。 • EKSなどのマネージドなKubernetesサービスを利用している場合、 その上で動かすのも現実的な選択肢。
32. 32 マイクロサービスの原則：Database per Service • 共有DBではなく、サービス単位のDB。 • 論理的な分割でも良いが、障害時の波及範囲を抑える必要あり。 BFF 注文管理 商品 配送 顧客 参照系 Pod Pod Pod Pod Pod Pod
33. 33 転ばぬ先の PostgreSQL on Kubernetes アンチパターン • 使ってはいけない時 • Kubernetesを良く知らない • 移行元のPostgreSQLが巨大で、フルチューンされている ⇒ どうしてもという場合はDB分割を検討した方が良い • 使わない方が良い時 • オートスケールを想定している場合 ⇒ 現状ではマネージドサービスのオートスケールを選ぶべき • 分散ストレージなどと組み合わせるケース ⇒ 複雑性が各レイヤに存在し、障害ケースの想定が難しい • Kubernetesの外側にバックアップを取れないケース ⇒ クラスタ全損まで考慮すべき
34. 34 ちょっと変わった マネージド の世界 5
35. 35 クラウドは当たり前の時代、 • 偉い人はこう言いました。 注：フィクションです。 「A◦Sの障害が起きたら、 どうするんだ!! マルチクラウドにしろ！ 」
36. 36 マルチクラウド対応のサービス例：Box Zones • 頑張れば出来るが、コストは当然高い。 Tokyo Osaka USA 複製 R P メタデータ 「さて、ファイルは、、、」 • 左図はBox社の “Box Zones Japan” の構成イメージ。 • 実際のファイルは、 AWS東京とAzure大阪に 二重化される。 • メタデータは米国に。 • つまり、 マルチ＋ハイブリッド
37. 37 マネージドサービスの大きな流れ • クラウドプロバイダが提供するマネージドサービス(DBaaS) は、 事業者の障害でサービス全断の可能性がある。 • 独自拡張のPostgreSQLのために、移植性や将来性に懸念が残る 部分もある。 • ユーザニーズに応えるために、マルチクラウドの対応は今後更に 加速する。 • そして、サービス展開のプラットフォームとして、Kubernetes を使う形も見られるようになっている。 • ピュアPostgreSQLを、マルチクラウドかつグローバルに展開し、 顧客のビジネスをサポート可能なサービスが出てきている。
38. 38 Azure Arc enabled data servicesとは • Azure data servicesをオンプレ/マルチクラウド/エッジに展開。 Azure Arc DB管理 • オンプレ/Azure他のクラウド、 エッジのKubernetesクラスタに Azure data servicesを展開可能。 • つまり、Hyperscale(Citus)を Kubernetesクラスタがあれば、 どこでも利用可能に。 • Azureによるフルマネージドな DBaaS、ただしロケーションを 選択可能。 • 現時点でプレビュー版。
39. 39 Hyperscale(Citus)とは • ノード間でデータを分割して保持、 一つのDBのように見せる。 • コーディネータが処理を振り分け、 負荷を分散する。 • AzureのHyperscale(Citus)はシャー ド毎のデータも冗長化されている。 • 多数のノードを管理する必要があり、 マネージドで運用負荷を軽減する効果 が大きい。 • PostgreSQLをスケーラブルな分散データベースにする拡張。 • マネージドサービスとしては、Azureが提供している。 コーディネータ
40. 40 つまり、マネージドサービスの意味が拡張される？ • Kubernetesさえあれば、マネージドサービスがどこでも・ 何でも管理できるようになってきている。 ベアメタル EC2 ホスト コンテナ ランタイム オーケスト レーション IaaS マネージドサービス (DBaaS) Kubernetes Service オンプレミス Kubernetes EKS マネージドサービスとは 何をマネージするのか？ 実はこの辺りも？
41. 41 マネージドサービスはオンプレミスを取り込むか？ • クラウドとオンプレの境界をぼかす仕組みとも言える、 Azure StackやAWS Outpostsが既にリリースされている。 対象サービス 特徴 RDS on Outposts •PostgreSQL対応はもちろん、 Auroraも稼働する。 EKS •Kubernetesが動けば、つまり。 EC2 •当然、VM環境としても使える。 EBS （AWS Outpostsの筐体イメージ）
42. 42 マルチクラウドに展開可能な、Crunchy Bridge • Crunchy Dataが展開するマネージドPostgreSQL。 US East East US メインサイト DRサイト • AWSとAzureを選択可能。 • マルチリージョンなレプリカ展開 が可能。 • マルチクラウドなレプリカ展開も 可能。 • DRやクラウドプロバイダの障害に 対応できる。 • 展開できるリージョンに制限あり。 • 現状で日本は未展開。
43. 43 どんな時に使うのか？ ちょっと変わったマネージド • マルチクラウドの可用性を担保したい時。 • Sharding(Citus)なマネージドPostgreSQLを利用したい時。 • マルチクラウドの要件を持つビジネスは多いとは言えないが、 マルチリージョンはDRで求められるケースがある。 • 発展途上であることを理解し、PoCから慎重に行う必要あり。 • DBaaSのコントロールプレーンがどこにあるかは、気にしない 時代に入るかもしれない。課金単位などにも注意が必要。
44. 44  パブリッククラウドで PostgreSQLを使う際の選択肢、 どれぐらい知っていますか。  RDS、Auroraなど各サービスの特徴を理解しましょう。  昨今のクラウド上ではコンテナ、 Kubernetesを前提と したサービスも出てきています。  それらの仕組みは理解して、これからのビジネスに最適な PostgreSQLプラットフォームを一緒に考えましょう。 （再掲）本日のゴール 豊富なPostgreSQLプラットフォームの選択肢を 理解して、使いこなそう！
45. 45 Questions? @tzkb @tzkoba