Kubernetes Operatorに対応するEDB Postgresについて

2021.01.20

PostgreSQLのエンタープライズ向けサブスクリプションで最大の実績を持つEnterpriseDBより、KubernetesのOperatorに対応するソリューションのロードマップが公開されました。

本日はEDBがなぜKubernetesに対応するのか？そして、Operatorが必要とされる理由、そもそもOperatorとは？をまとめてみました。

なぜデータベースもKubernetes？

コンテナを使⽤した本番環境は複数のホストでクラスタ構成を組み利⽤される事が通常です。

これは、コンテナ単体では可⽤性が低く、データも揮発性が⾼いといわれるため、複数のコンテナをグループにまとめて管理することで、サービスの停止が許されない本番環境でも高い可⽤性を担保することを⽬的にしています。

また、数百個、時には数万ともなるコンテナを1つ1つ管理していては管理⾯での負担が⾮常に⾼くなるため、Podと呼ばれるグループ単位の管理や⼤規模に展開を行える自動化された運用の仕組みが求められます。

KubernetesのOperatorとは？

Operatorの目標は、これまで人の手で行われていた運用の知識をソフトウェアに組み込むことです（運用のコード化＝IaC：Infrastructure as Code）。

以前は、この運用の知識はシステム管理者により、シェルスクリプトのさまざまな組み合わせ、またはAnsibleのような自動化ソフトウェアにより実現されていました。これはKubernetesクラスターの外側にあり、統合するのが困難でした。

Operatorは、Kubernetesに運用の知識をネイティブに統合することにより、Kubernetesクラスター内で実行されているソフトウェアのデプロイ（インストールから構成）および運用（再構成、更新、バックアップ、フェイルオーバー、復元など）におけるアクティビティを実装および自動化します。

Operatorはコミュニティにより多数公開されており、OperatorHubより検索・取得・利用することができます。

Kubernetes Operatorの自動化レベル

Operatorでは、提供するアプリケーションまたはワークロードのライフサイクル管理機能に関してさまざまなレベルがあります。自動化レベルは、ユーザーがOperatorに期待できる機能を表現するための指標として見ることができます。

Level1：Basic Install

利用技術：HELM, ANSIBLE, GO

  • ワークロードのインストール
    • Operatorがオペランドをデプロイするか、クラスター外のリソースを構成します
    • Operatorは、管理対象リソースが正常な状態に達するのを待ちます
    • Operatorは、カスタムリソースのステータスブロックを利用して、アプリケーションまたは管理対象リソースの準備状況をユーザーに伝えます
  • ワークロードの構成
    • Operatorは、カスタムリソースの仕様セクションを介して構成を提供します
    • Operatorは、構成と更新を管理対象リソースのステータスと調整します

Level2：Seamless Upgrades

利用技術：HELM, ANSIBLE, GO

  • 管理対象ワークロードのアップグレード
    • オペランドは、演算子をアップグレードする過程でアップグレードできます
    • CRの変更の一環としてオペランドをアップグレードできます
    • Operatorは、以前はOperatorの古いバージョンによって管理されていた、古いバージョンのオペランドをアップグレードする方法を理解しています
  • Operatorのアップグレード
    • Operatorはシームレスにアップグレードでき、古いバージョンのオペランドを引き続き管理するか、更新することができます
    • Operatorは、CRのステータスセクションで、サポートされていないバージョンのオペランドを管理できないことを伝えます

Level3 : Full Lifecycle

利用技術：ANSIBLE, GO

  • Operatorは、以下のライフサイクル管理機能の1つ以上を提供します
    • Operatorは、オペランドのバックアップを作成する機能を提供します
    • Operatorはオペランドのバックアップを復元できます
    • Operatorは、オペランドで複雑な再構成フローを調整します
    • Operatorは、クラスター化されたオペランドのフェイルオーバーとフェイルバックを実装します
    • Operatorは、クラスタ化されたオペランドへのメンバーの追加/削除をサポートします
    • Operatorは、オペランドのアプリケーション対応のスケーリングを可能にします

Level4 : Deep Insights

利用技術：ANSIBLE, GO

  • モニタリング
    • Operatorがその状態に関するメトリックを公開
    • 演算子は、オペランドに関するヘルスとパフォーマンスのメトリックを公開します
  • アラートとイベント
    • オペランドは有用なアラートを送信します
    • カスタムリソースはカスタムイベントを発行します
  • メータリング
    • Operatorはオペレーターメータリングを活用します

Level5 : Auto Pilot

利用技術：ANSIBLE, GO

  • 自動スケーリング
    • Operatorは、オペランドメトリックに基づいて、負荷が増加した場合にオペランドをスケールアップします
    • Operatorは、オペランドメトリックに基づいて、オペランドを特定の負荷以下に縮小します
    • Operatorは、オペランドのメトリック/アラート/ログに基づいて、異常なオペランドを自動的に修復できます
    • Operatorは、オペランドのメトリックに基づいて、オペランドが異常な状態に移行するのを防ぐことができます
  • オートチューニング
    • Operatorは、オペランドを特定のワークロードパターンに自動的に調整できます
    • Operatorは、ワークロードを最適なノードに動的にシフトします
  • 異常検出
    • Operatorは、標準のパフォーマンスプロファイルからの逸脱を判断します

まとめ

Kubernetes Operatorを利用することでコンテナ管理のデプロイから運用までのライフサイクルが自動化できるため、注目度の高い技術になります。EDB社ではこのOperatorへの対応をいち早く開始し、2021年のはじめに第2世代のアーキテクチャをリリースする予定です。

コンテナでのデータベースはエンタープライズレベルでの利用となると信頼性の面で導入をためらう方も多かったのではないでしょうか、EDB Postgres のKubernetes Operatorではこの不安を払拭して、より高いレベルの信頼性を発揮することが期待されています。ぜひ、今後もEDB社のリリースにはご注目ください。