サービス単体の可用性を確保するのに有効な2つのパターン
続いて早川氏は、Kubernetesでの可用性を考える上で必要な2つ目のポイント、「サービス単体の可用性の確保」に触れた。個々のサービスの観点では、モノリシックなアプリケーションに適用していた従来型の障害対策が有効だが、さらにKubernetesの機能を組み合わせることで、より高度な可用性構成が実現できる。
「まずは従来どおり、SPOF（Single Point of Failure）を生じさせないためにサービス内の構成要素を冗長化し、障害からの回復性を念頭に置いて設計します。そしてこれらを、Kubernetesの自律回復の機能を活用して実装していきます」
それらの実装例として、早川氏は以下の2つのパターンを紹介する。
【Replicated Database】MySQLの冗長構成＋自動再起動
- Kubernetesの「Service」オブジェクトの使い分けで、マスターおよびリードレプリカへのアクセスを適切にルーティングする。
- Kubernetesの「StatefulSet」を使って、データベースの自動再起動を実装する。
【死なないKafka】透過的に自律回復するクラスター
- オープンソースの分散メッセージングシステム「Apache Kafka」のBrokerをKubernetesに分散配置。
- Kubernetesの「Statefulset」とKafkaクラスターの自律調整機能を組み合わせて、障害時にもクライアントから見て透過的に自律回復する。
さらに早川氏は、「Kafka Brokerを使った構成は有効だが、本番運用を考えるとまだまだ克服すべき課題があります。例えば復旧時の負荷を考慮したサイジングが必要であることや、ノードやデータセンターごと停止するケースを想定して、ミッションクリティカルのシステムではインフラレベルの可用性を考慮しなくてはなりません」と付け加える。
ほとんどの機能がOSSで構成されているOracleのKubernetesマネージドサービス
さらに早川氏は、OracleがミッションクリティカルシステムにおけるKubernetes活用への解として、現在急ピッチで開発を進めている「Container Native Application Development Platform（CNP）」を紹介する。
CNPとは、Kubernetesと周辺ツールおよびフレームワークを一括提供するマネージドサービスだ。その特徴として、大きく以下の2つが挙げられる。
安全な運用と開発への専念を実現するマネージドサービス
CNPはKubernetesを中心としたコンテナベースの開発に必要な機能を網羅している。さらにそれらをアウト・オブ・ボックスで利用可能であり、開発者は基盤の構築管理から開放されてアプリケーションの可用性設計に専念できる。
また、ほとんどの機能をオープンソースソフトウェア（OSS）で構成しているため、ベンダーロックインを回避できる。
ミッションクリティカルな可用性を実現する基盤
障害復旧時の負荷に耐えるには、安定したパフォーマンスが必須要件となる。CNPはその実行基盤として、パフォーマンスと可用性に優れた、Oracleの第2世代IaaS（Oracle Cloud Infrastructure：OCI）を採用している。
OCIは高速SSDを搭載したベアメタル（非仮想）サーバーを採用しており、サーバー単体のパフォーマンスが非常に高い。さらに、3つのAvailability Domains（AD）によるデータセンターの冗長化と、AD間およびAD内のホスト間をつなぐ高速ネットワークにより、高い可用性と性能を両立する設計となっている。
CNPはこの次世代IaaSの力を生かして、大規模障害に耐える高可用性Kubernetesクラスターを提供する。
Oracleでは正式リリースに先立ち、すでにCNPの一部クラスターを公開しており、今すぐに体験できる環境が用意されているという。
「『Container Pipelines（Wercker）』『Apiary』『OCI（Oracle Cloud Infrastructure＝IaaS）』は、今すぐに使うことができます。またTerraformベースのKubernetesインストーラも公開済みです。ぜひ、Oracleの新しいプラットフォームを体験して、自社へのミッションクリティカルKubernetes導入に役立ててください」
最後に早川氏はこう語り、セッションを終えた。
お問い合わせ
日本オラクル株式会社
- TEL：0120-155-096（Oracle Direct）
- Oracle Cloud 詳細ページ
