PostgreSQLの プラットフォーム徹底比較！ ～ クラウドからコンテナまで ～ PostgreSQL Conference Japan 2020 , 11/13 Takahiro, Kobayashi ( @tzkb)

2 最近やっていること • PGConf.Asia 2019 “Building PostgreSQL as a Service with Kubernetes” • July Tech Festa 2020 “マイクロサービスの今こそ！ 理解して拡げる分散システムの基礎知識” ＋ ＝∞

3 1. あなたのDBはどこに？ 2. まずはここから、RDS for PostgreSQL 3. そしてAuroraの世界へ 4. PostgreSQL on Kubernetesという選択肢 5. ちょっと変わった マネージド の世界 アジェンダ

4 あなたのDBはどこに？ 1

5 PostgreSQLプラットフォームを整理してみると • 現在はオンプレミスからクラウド(マネージドサービス含む)、 コンテナまで様々な環境でPostgreSQLが稼働する。 ベアメタル EC2 ホスト コンテナ ランタイム オーケスト レーション IaaS マネージドサービス (DBaaS) Kubernetes Service オンプレミス Kubernetes EKS Amazon Aurora Amazon RDS 本日の対象

6 ポスグレのプラットフォームは？ @PostgreSQLアンカンファレンス 2020 • オンプレが健在（回答者に若干の偏りあり）。 • VMベースが多いけど、ベアメタルとクラウド同数ぐらい？ • サービス別ではAmazon RDSが抜けているが、Auroraも多い。

7 マネージドなデータベースを使うのはなぜ？ （建前） • ベストプラクティスでしょ？ • 構築もらっくらく。 • 運用もほぼ自動。 （本音） • インストールとか面倒。 • 開発が本業。DBAいない。 • おれたちは雰囲気でDBやってる。 DB

8  パブリッククラウドで PostgreSQLを使う際の選択肢、 どれぐらい知っていますか。  RDS、Auroraなど各サービスの特徴を理解しましょう。  昨今のクラウド上ではコンテナ、 Kubernetesを前提と したサービスも出てきています。  それらの仕組みは理解して、これからのビジネスに最適な PostgreSQLプラットフォームを一緒に考えましょう。 本日のゴール

9 まずはここから、RDS for PostgreSQL 2

10 (今更ですが) Amazon RDS for PostgreSQLとは • AWSが運用してくれる PostgreSQL。 • コミュニティで開発されているピュアPostgreSQLで、これまで 自身のサーバにインストールしていたものと、同じものが使える （但し一部の拡張は使えない）。 • インフラ構築不要、インストールも不要で使い始められる。 • バックアップ・リストアも簡単。 • Multi-AZで高可用性を担保、リードレプリカも構築できる。 • 各種メトリクスもAWSコンソールから確認可能。

11 RDS for PostgreSQLがもたらす効果 電源、ラック サーバ管理 OSインストール OSパッチ DBインストール DBパッチ バックアップ/リストア HA スケール アプリケーション 電源、ラック サーバ管理 OSインストール OSパッチ DBインストール DBパッチ バックアップ/リストア HA スケール アプリケーション オンプレミス Amazon RDS ユーザ による管理 による管理

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 どんな時に使うのか？ RDS for PostgreSQL • 使わない理由がない。 • AWSでPostgreSQLを使うなら、 特定バージョンや特殊なエクステンションが必要な時を除き、 いつでも。 • これまでの運用・チューニングスキルがそのまま活かせるのも ポイント。  例：Autovacuum関連のパラメータ設定等は基本的に流用可能で、 ワークロードに最適されたPostgreSQLを利用できる。

14 そしてAuroraの世界へ 3

15 Amazon Auroraとは • クラウド向けに構築された、PostgreSQL互換のDBMS。 • つまり、ピュアなPostgreSQLではない。 • 商用DBと同等のパフォーマンスと可用性を1/10のコストで実現 することを目標としている。 • Multi-AZよりも高い3-AZの可用性を実現。 • 高い性能(PostgreSQL互換では3倍とも)と拡張性。 • エンタープライズのニーズに応える各種サービスを展開。  Aurora Serverless  Global Database  マルチマスタークラスタ

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 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 たくさんのAuroraファミリー Auroraの各種サービス 特徴 Aurora PostgreSQL 互換エディション 3つのAZに跨る6つのレプリカを保持し、高い可用性を持つ。 AWSに最適化された構成で約3倍と言われる高い性能。 ※他と区別するために、Aurora Provisioned Clusterとも。 Aurora Serverless アプリケーションのワークロードに応じて、DBクラスタを自動的 に起動・停止し、スケールアップ/ダウンを行う。 Global Database 複数のAWSリージョンに跨ってレプリカを構築可能。リージョン 障害時には切り替えることでDR対応ができる。 マルチマスタークラスタ 2つのプライマリインスタンスを構成可能、ダウンタイムをより短 縮できる。 ※PostgreSQLでは未対応 • 一言でAuroraといっても、、、使い分けられますか？

19 Amazon Aurora Serverlessとは Compute Storage Storage Storage • リクエストベースでインスタンスを起動、無風時は停止も可能。 • つまり、ゼロスケールが可能なDBクラスタと言える。 Request Router VPC Endpoints NLB • オンデマンドにCompute(インスタンス) は起動され、利用していない時は 停止される。 • 停止時はストレージ料金のみ。 • 基本的には特定AZのComputeが スケールアップ/ダウンする。 • 障害時は別AZでComputeを起動 するが、FO時間は未定義。

20 Aurora Serverlessの注意点 • 柔軟性は理想的にも見えるが、通常のAuroraとは大きく異なる。 • AWSでは次のようなユースケースを想定。  利用頻度が少なく、不定期なワークロード  負荷が予測できないワークロード  開発やテスト環境として • PostgreSQLバージョンは、10.7のみ。 • 通常のAuroraで使える拡張・AWSサービスも使えない。  postgres_fdw  Performance Insightなど そもそもAuroraを使うべき？

21 Amazon Aurora Global Databaseとは R P R • Region(地域)を跨いで、Auroraのレプリケーションが可能。 • Region障害があった際に、もう一方でサービスを継続できる。 Primary Region Secondary Region • DBMSレベルではなく、 ストレージレベルのレ プリケーション。 • レプリケーションのレ イテンシは低く保たれ、 通常1分以内でFOが 可能とされている。

22 どんな時に使うのか？ Amazon Aurora • より高い可用性、性能を求める時（＞コスト）。 • Oracle(そしてExadata)などの商用の高性能・高可用性DBからの 移植に向いている。 • Oracle Data Guard等のソリューションを使っていた場合にも。 • ピュアPostgreSQLでない点には注意。 • 「クエリ実行計画の管理」など、Aurora独自機能の理解や使い方 を理解する必要あり。 • 運用やコストの考え方で、Aurora固有の考慮ポイントが出てくる ため、それらに習熟する必要がある。

23 PostgreSQL on Kubernetesという選択肢 4

24 PostgreSQL on Kubernetesとは • コンテナ向けプラットフォーム(オーケストレータ)である、 Kubernetes上でPostgreSQLを稼働させる構成。 • (コンテナイメージがあれば) どのバージョンのPostgreSQLも 利用できる。拡張も自由に組込み可能。 • IaCとの相性が良く、宣言的にPostgreSQLの実行できます。 • お手持ちのKubernetesで（ ）、すぐにお試し可能です。 え、Kubernetesって？？

25 PostgreSQL on Kubernetesが出来ること 電源、ラック サーバ管理 OSインストール OSパッチ DBインストール DBパッチ バックアップ/リストア HA スケール アプリケーション on K8sクラスタ による管理 バージョン選択 任意のバージョンを選べる リソース上限 Nodeのキャパシティ次第 リソース下限 CPUはmill core単位で指定可 パラメータ 全て変更可能 Extension 全て導入可能 OSログイン 可能（任意のユーザ作成も可）

26 マネージドPostgreSQLと比較して • マネージドは便利だが、全工程で最適とは限らない。 特徴 • 開発者向け • 1人で1DBが理想 • ユーザ/内部テスト • リリース確認用 • 本番サービス用 マネージド 向き？ • No. • スキーマも辛いが1人 1インスタンスも辛い • Yes. • インスタンスが増え ていくことも。 • Yes. • 可用性も担保できる 開発環境 テスト/ステージング 本番環境

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 テスト環境も柔軟に拡張できる 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 本番環境では、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 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 どんな時に使うのか？ PostgreSQL on Kubernetes • アプリケーションをKubernetesで動かしている時。 • マネージドサービスより柔軟なリソース配分を行いたい時。 • マイクロサービスと組み合わせるケース。大量に乱立する インスタンスの管理コストを下げる可能性を秘めている。 • 開発・テスト環境でのコンテナDB利用は加速すると思われる。 • なお、Kubernetes自体の管理はDBに限らず、大きな課題。 • EKSなどのマネージドなKubernetesサービスを利用している場合、 その上で動かすのも現実的な選択肢。

32 マイクロサービスの原則：Database per Service • 共有DBではなく、サービス単位のDB。 • 論理的な分割でも良いが、障害時の波及範囲を抑える必要あり。 BFF 注文管理 商品 配送 顧客 参照系 Pod Pod Pod Pod Pod Pod

33 転ばぬ先の PostgreSQL on Kubernetes アンチパターン • 使ってはいけない時 • Kubernetesを良く知らない • 移行元のPostgreSQLが巨大で、フルチューンされている ⇒ どうしてもという場合はDB分割を検討した方が良い • 使わない方が良い時 • オートスケールを想定している場合 ⇒ 現状ではマネージドサービスのオートスケールを選ぶべき • 分散ストレージなどと組み合わせるケース ⇒ 複雑性が各レイヤに存在し、障害ケースの想定が難しい • Kubernetesの外側にバックアップを取れないケース ⇒ クラスタ全損まで考慮すべき

34 ちょっと変わった マネージド の世界 5

35 クラウドは当たり前の時代、 • 偉い人はこう言いました。 注：フィクションです。 「A○Sの障害が起きたら、 どうするんだ!! マルチクラウドにしろ！ 」

36 マルチクラウド対応のサービス例：Box Zones • 頑張れば出来るが、コストは当然高い。 Tokyo Osaka USA 複製 R P メタデータ 「さて、ファイルは、、、」 • 左図はBox社の “Box Zones Japan” の構成イメージ。 • 実際のファイルは、 AWS東京とAzure大阪に 二重化される。 • メタデータは米国に。 • つまり、 マルチ＋ハイブリッド

37 マネージドサービスの大きな流れ • クラウドプロバイダが提供するマネージドサービス(DBaaS) は、 事業者の障害でサービス全断の可能性がある。 • 独自拡張のPostgreSQLのために、移植性や将来性に懸念が残る 部分もある。 • ユーザニーズに応えるために、マルチクラウドの対応は今後更に 加速する。 • そして、サービス展開のプラットフォームとして、Kubernetes を使う形も見られるようになっている。 • ピュアPostgreSQLを、マルチクラウドかつグローバルに展開し、 顧客のビジネスをサポート可能なサービスが出てきている。

38 Azure Arc enabled data servicesとは • Azure data servicesをオンプレ/マルチクラウド/エッジに展開。 Azure Arc DB管理 • オンプレ/Azure他のクラウド、 エッジのKubernetesクラスタに Azure data servicesを展開可能。 • つまり、Hyperscale(Citus)を Kubernetesクラスタがあれば、 どこでも利用可能に。 • Azureによるフルマネージドな DBaaS、ただしロケーションを 選択可能。 • 現時点でプレビュー版。

39 Hyperscale(Citus)とは • ノード間でデータを分割して保持、 一つのDBのように見せる。 • コーディネータが処理を振り分け、 負荷を分散する。 • AzureのHyperscale(Citus)はシャー ド毎のデータも冗長化されている。 • 多数のノードを管理する必要があり、 マネージドで運用負荷を軽減する効果 が大きい。 • PostgreSQLをスケーラブルな分散データベースにする拡張。 • マネージドサービスとしては、Azureが提供している。 コーディネータ

40 つまり、マネージドサービスの意味が拡張される？ • Kubernetesさえあれば、マネージドサービスがどこでも・ 何でも管理できるようになってきている。 ベアメタル EC2 ホスト コンテナ ランタイム オーケスト レーション IaaS マネージドサービス (DBaaS) Kubernetes Service オンプレミス Kubernetes EKS マネージドサービスとは 何をマネージするのか？ 実はこの辺りも？

41 マネージドサービスはオンプレミスを取り込むか？ • クラウドとオンプレの境界をぼかす仕組みとも言える、 Azure StackやAWS Outpostsが既にリリースされている。 対象サービス 特徴 RDS on Outposts •PostgreSQL対応はもちろん、 Auroraも稼働する。 EKS •Kubernetesが動けば、つまり。 EC2 •当然、VM環境としても使える。 EBS （AWS Outpostsの筐体イメージ）

42 マルチクラウドに展開可能な、Crunchy Bridge • Crunchy Dataが展開するマネージドPostgreSQL。 US East East US メインサイト DRサイト • AWSとAzureを選択可能。 • マルチリージョンなレプリカ展開 が可能。 • マルチクラウドなレプリカ展開も 可能。 • DRやクラウドプロバイダの障害に 対応できる。 • 展開できるリージョンに制限あり。 • 現状で日本は未展開。

43 どんな時に使うのか？ ちょっと変わったマネージド • マルチクラウドの可用性を担保したい時。 • Sharding(Citus)なマネージドPostgreSQLを利用したい時。 • マルチクラウドの要件を持つビジネスは多いとは言えないが、 マルチリージョンはDRで求められるケースがある。 • 発展途上であることを理解し、PoCから慎重に行う必要あり。 • DBaaSのコントロールプレーンがどこにあるかは、気にしない 時代に入るかもしれない。課金単位などにも注意が必要。

44  パブリッククラウドで PostgreSQLを使う際の選択肢、 どれぐらい知っていますか。  RDS、Auroraなど各サービスの特徴を理解しましょう。  昨今のクラウド上ではコンテナ、 Kubernetesを前提と したサービスも出てきています。  それらの仕組みは理解して、これからのビジネスに最適な PostgreSQLプラットフォームを一緒に考えましょう。 （再掲）本日のゴール 豊富なPostgreSQLプラットフォームの選択肢を 理解して、使いこなそう！

45 Questions? @tzkb @tzkoba