こんにちは、Red Hatでソリューションアーキテクトをしている北村です。

みなさん、OpenShiftのアップグレードしていますか？Kubernetesを運用する上で避けて通れないのがクラスターのライフサイクル管理です。Kubernetesは従来のプラットフォームよりもバージョンアップの頻度が多くサポート期間が短いので、定期的なバージョンアップ対応が必要になります。そしてそれはKubernetesのディストリビューションであるOpenShiftも同様です。

しかしクラスターアップグレードを実行する際、インフラの構成やアプリケーションの作り、マニフェストの設定などによってサービス断が発生する可能性があります。そのためサービスの可用性を最優先するためのアップグレード戦略として複数クラスターによるBlue/Greenアップグレードを採用するケースがあります。

とはいえBlue/Green構成を組むのも一苦労な上、クラスターの切り替えも色々な方法があるので、どの方法を採用するかを検討するのも大変です。そこで今回は、このBlue/GreenアップグレードをAWS上のOpenShiftで実現する際のクラスター切り替え方式についてまとめてみました。

今回取り扱う切り替え方式

今回は以下の4つの方式についてまとめました。

DNS切り替え
Cloud Front切り替え
HAProxy切り替え
Global Accelerator切り替え

DNS 切り替え

Blue/Greenの切り替えで一番メジャーな方法がこのDNS切り替えだと思います。対象のレコードのルーティング先を片方のクラスターに向け、サービスアウトした上でアップグレードを実行します。

AWSのRoute 53を利用する場合、加重ルーティングを活用するとレコードの追加・削除をすることなく、重量のみを変更して通信の切り替えを実現できます。サービスアウトしたい方のレコードの重量を0に変更することで、1以上の重量を設定したレコードのみ利用されます。両方0にすると同じ流量でルーティングされますが、このように通信切り替えを行うことを想定して、通常は1以上の重量を設定しておきます。

この手法での注意点はやはりTTLの管理になります。レコードの伝播もさることながら、このTTLが切れるまでは切り替えは発生しないため、そのタイムラグを許容できるかが採用のポイントになります。なおRoute 53ではCLBの宛先をAliasレコードとして登録することができますが、AliasレコードのTTLはルーティング先のサービスの仕様に依存します。CLBの場合はTTLが60秒となるため、これより短くしたい場合はCNAMEでの登録を検討ください。

DNS切り替えは設定箇所も少なく、プライベートホストゾーンを使うことで非インターネット環境でも利用可能なため、多くの環境でこの手法を採用することが可能です。Blue/Greenを実装する場合、まずはこの方式から検討することをおすすめします。

CloudFront 切り替え

AWSのマネージドCDNサービスであるCloudFrontを利用して切り替えることもできます。 Route 53でドメインの宛先をCloud Frontに向けつつ、CloudFront側の設定変更でクラスターへの通信を制御します。この際キャッシュが効いているとキャッシュのTTL分だけ切り替えが行われないため、切り替えを素早く実施する場合はCloudFrontのキャッシュのTTLを0秒に設定しておきましょう。

切り替え時間についてはDNSより早く切り替えが実現できる印象がありますが、この点はCloudFrontの設定変更の伝播に依存するため、自分の環境で試してみた方が良いかと思います。ちなみに私が試した際はおおむね20秒前後で切り替えができました。

この手法の注意点は、インターネット公開環境しか利用できないことと、通常時にAct/Actの構成を組めないことになります。ビヘイビアに複数のオリジンを指定することは可能ですが、優先順位が設定されるためラウンドロビンのような通信の分散はできません。DNSのTTLの考慮が面倒くさかったり、レコードの設定変更が権限上難しい場合に検討いただくと良いかと思います。

HAProxy 切り替え

自前のEC2インスタンス上にHAProxyを構築して、Configによる切り替えを実現します。

この手法の強みは、HAProxyによる柔軟なルーティング設定/ログ設定が可能なことと、通信の即時切り替えが可能な点です。今回紹介する手法の中で唯一、通信の即時切り替えができるため、アプリの要件としては採用する可能性が高い手法になります。

ただし他の手法とは異なり、構成するコンポーネントがマネージドサービスでないため、障害への対策やパフォーマンスのチューニングをきちんと設計する必要があります。下の図ではHAProxy 環境を単一のインスタンスで表現していますが、複数AZへの配備やAutoscaling Groupの利用、インスタンスの前段にさらにELBを設置するなど、本番環境として構成する場合は検討項目が多いことにご注意ください。

Global Accelerator 切り替え

かなりマイナーな選択肢になりますが、Global Acceleratorを利用してクラスターの切り替えを実現することも可能です。クラスターのエンドポイントをGlobal Acceleratorリスナーのエンドポイントグループに登録し、”重み”の設定を変更することでクラスター切り替えを実現します。

この手法はGlobal Acceleratorの仕様上CLBをエンドポイントに指定できないため、Service（Type: LoadBalancer）などで別途NLBを立てる必要があります。この場合はRouter独自の機能（TLS終端など）が使えないため、個別の設定考慮が必要です。Service個々にURLを設定するため、ワイルドカードドメインの利用もできなくなります。

切り替えについてはエンドポイントごとに設定する”重み”をコントロールして実現します。Route 53の加重ルーティングと同様、サービスアウトしたいエンドポイントの”重み”を0にすることで片方のクラスターのみに通信を流すことができます。この手法はCloudFront同様、インターネット公開環境のみでの利用、かつグローバルのエッジロケーションに設定が伝播するまでタイムラグがあるため、これらの特性を理解した上で採用を検討してください。

ぱっと見ると”CloudFront切り替え”の劣化版のように見えますが、この手法では通常時にクラスターのAct/Act構成を取ることができます。そのため、Route 53での切り替えが困難だけど、Act/Act構成をとっておきたいといった要件があった場合はこの手法を選択肢のひとつとして検討していただければと思います。