予期せぬアップグレード障害を防ぐには
業務システムをクラウドへ移行することには、数多くのメリットがあります。マネージドサービスを使う最大の利点のひとつは、自社のインフラ・技術リソース・運用プロセスでサービスを維持し続ける必要がなくなることです。利用料を支払う代わりに、提供事業者の幅広いノウハウと経験を活用できます。データベースのマネージドサービスにも、セキュリティ、リソース割り当て、機能統合など多くのメリットがあります。
本記事では、複数のクラウドプロバイダーが提供している、一見すると日常的なメンテナンスを楽にしてくれそうな、ある機能について取り上げます。しかし実際には、ビジネスに深刻なダメージを与えかねない代償が潜んでいます。重大な障害を引き起こし、しかも自社運用時代に培った技術リソースやスキルがすでに失われた状況下で、まったく備えのない事態に直面しかねないのです。
その機能とは「マイナーバージョンの自動更新」です。
なぜ製品アップグレードが重要なのか
どの組織にも、長年の経験、製品、業務に固有の社内ツールに基づいて構築された独自のプロセスや管理体制があります。それが堅牢な場合もあれば、最低限のレベルにとどまる場合、あるいは脆弱な場合もあります。マネージドサービスを使うと安定性や運用力が向上したように感じられますが、必要なテスト工程までなくなるわけではありません。クラウドもマネージドサービスも、自動化、IaC、各種フレームワークも、適切なプロセス管理の必要性をなくしてはくれません。
データベースは、あらゆるビジネスにとって重要なコンポーネントの一つです。唯一の重要要素ではないにせよ、多くの組織においてデータベースが動かない状況は、事業運営能力に甚大な影響を及ぼします。
すべての製品では、時間とともに機能や構文の非推奨化、サポート終了の通知、セキュリティパッチの提供が行われます。こうした変更に対応するには、アプリケーションを支えるインフラを継続的にメンテナンスする必要があります。製品アップデートには マイナーアップグレードとメジャーアップデート の2種類がありますが、ビジネスリスクの観点では、いずれも同等に扱うべきです。
テストされていないマイナーアップグレードが、本番システムを停止させることがあります。
マネージドサービスの既定のアップグレード方式
多くのクラウドプロバイダーは、マイナーバージョンアップグレードを含む、繰り返し作業や定型作業を処理するためのツールや自動化機能を数多く提供しています。
以下はAWS RDSの例です。AWSコンソールで新しいデータベースを作成すると数十項目の設定オプションが表示されますが、それで全部ではありません。ページ下部の「追加設定(Additional Configuration)」を開くと、すべてのセットアップオプションが表示されます。
その追加ページの最下部までスクロールすると、メンテナンス(Maintenance)セクション があり、「マイナーバージョン自動アップグレードを有効化(Enable auto minor version upgrade)」が既定でオンになっています。
このマネージドサービス方式の問題点
この既定設定をそのまま使うことには、いくつかの根本的な問題があります。
- マイナーアップグレードは、AWSの判断で週次のメンテナンスウィンドウに適用されます。次のメンテナンスウィンドウで自動的に行われるとは限らず、数週間先になることもあります。
- AWSはテスト環境と本番環境を区別しません。複数の環境で自動アップグレードを有効にしている場合、その週にすべての環境で同時に実施されることもあれば、一部だけにとどまることもあります。
- AWSは、マイナーバージョンアップグレードに対して長期サポート(LTS)リリースを優先しません。AWS RDSのドキュメント にも「LTSバージョンに対してはAutoMinorVersionUpgradeパラメータをtrueに設定しないことを推奨します。設定するとDBクラスターが非LTSバージョンへアップグレードされる可能性があります」と明記されています。
- マイナーアップグレードが実行されても、AWS RDSは事後の問題発生時にロールバックできるリカバリーポイントを作成しません。point-in-time機能 を使ってデータベースをリストアすることはできますが、リストアしても現在稼働中のアップグレード済みバージョンが元のバージョンに戻るわけではありません。
- メンテナンスウィンドウは通常、システム利用が少ない時間帯に設定され、技術リソースが手薄な時間帯と重なりがちです。予定外のアップグレードがメンテナンスウィンドウ内で実行されると、停止時間がさらに延びる可能性が高くなります。
マイナーバージョンは、次のメンテナンスウィンドウで自動的に適用されるとは限りません。
マイナーバージョンアップグレードは、社内の新しい製品リリースと同じくらい重みのあるイベントです。技術リソースの大半が不在の時間帯に、未テストの社内製品リリースを本番環境へ自動デプロイするでしょうか?
マイナーバージョンアップグレードのベストプラクティス
答えは非常にシンプルです。テストして検証する こと。これに尽きます。
「マイナーバージョン自動アップグレードを有効化」は定期メンテナンスへの依存を減らしてくれる便利な機能ですが、その一方で、実行のコントロールやリカバリー手段への意識を希薄にしてしまいます。データベースは技術スタックの中核を担うコンポーネントであることが多く、他の重要なシステム構成要素と同じように、継続的な監視・管理・保守が欠かせません。
新しいマイナーバージョンを各環境に展開する際は、管理され、文書化されたプロセスに沿って進めるべきです。たとえば dev → test → stage → prod のように、本番に向けて段階的に環境を進めていく流れが基本になります。アップグレードは自動化で実行しつつ、データベースサーバーが何百、何千あっても、人による監視を併用すべきです。さらに、インフラを管理する運用担当者や、想定外・未テストの操作で問題が発生した際に対応できるエンジニアリソースが稼働している時間帯に実施すべきです。
アップグレードプロセスの個別ステップは組織ごとに異なります。ただし、必ず「アップグレード前」のスナップショット取得を組み込むべきです。一般的に、本番バージョンのリリースは、他の環境でリリース・検証してから十分な期間(数週間など)が経過した後に行うべきです。
本番データベースが、リリーステストサイクルで使われたどのデータベースよりも新しいバージョンであってはなりません。
最も古いポイントリリースのままデータベースを運用するのは賢明ではありません。マイナーバージョンアップグレードがクリティカルパス項目になってしまううえ、AWSは非推奨化や削除のスケジュールを公開していないからです。一方で、最新のポイントリリースで運用するのも一般には避けるべきです。最新リリースで持ち込まれた問題をコミュニティがまだ把握していない可能性があり、トラブルシューティングに役立つオンライン情報も限られているおそれがあるためです。
ベストプラクティスとして、各ポイントリリースはビジネスに適したタイミングで個別に展開し、1回のアップグレードで複数のマイナーバージョンをまとめて適用することは避けるべきです。新バージョンで修正された既知のバグなどが理由で最新版への展開が必要になるケースもあるため、文書化された通常のビジネスポリシーの枠を外れてでも、テスト・検証・アップグレードを実施せざるを得ない場合もあります。
要するに、常にプロアクティブであるべきです。
マイナーバージョンアップグレードの特定方法
ここ数か月のうちに、AWSはAWS CLIおよびコンソール経由でAWSの推奨事項を確認できる新機能を導入しました。これまでは、新バージョンの提供有無を判断するために、リリースノートの確認や新バージョンの追跡、この機能を有効化している他環境のイベント監視など、より手間のかかるプロセスが必要でした。
現在は describe-db-recommendations コマンドでこの情報を取得できます。注意:この機能はCLIバージョン2.15.3で利用可能になりました。変更履歴を一行ずつ 確認しないと、この最近の更新には気づきにくいかもしれません。CLIを頻繁に更新していない場合は、このコマンドを使うために新しいバージョンへの更新が必要です。
describe-db-recommendations の出力
$ aws rds describe-db-recommendations
{
"RecommendationId": "",
"TypeId": "config_recommendation::old_minor_version",
"Severity": "informational",
"ResourceArn": "arn:aws:rds:region:123456789:cluster:mydb",
"Status": "active",
"Detection": "**[resource-name]** is not running the latest minor DB engine version",
"Recommendation": "Upgrade to latest engine version",
"Description": "Your database resources aren't running the latest minor DB engine version. The latest minor version contains the latest security fixes and other improvements.",
"RecommendedActions": [\
{\
"ActionId": "",\
"Operation": "modifyDbCluster",\
"Parameters": [\
{\
"Key": "EngineVersion",\
"Value": "8.0.mysql_aurora.3.04.2"\
},\
{\
"Key": "DBClusterIdentifier",\
"Value": "mydb"\
}\
],\
"ApplyModes": [\
"immediately",\
"next-maintenance-window"\
],\
"Status": "ready",\
"ContextAttributes": [\
{\
"Key": "Recommended value",\
"Value": "8.0.mysql_aurora.3.04.2"\
},\
{\
"Key": "Current engine version",\
"Value": "8.0.mysql_aurora.3.04.1"\
}\
]\
}\
```\
### AWSコンソールでの表示\
AWSコンソールでRDSサービスを開くと、左側メニューに「Recommendations(推奨事項)」がハイライト表示されます。例:\
\
### **RDS推奨事項リスト**\
推奨事項リストには、「最新のマイナーDBエンジンバージョンで稼働していない」という推奨が付いたサーバー一覧が表示されます。\
\
### 個別の推奨事項の詳細\
推奨事項の詳細を開くと、リソースの完全な構成や、関連ドキュメントへの参照リンクを確認できます。\
\
まとめ\
ここで紹介した知見と、こうした通知を取得・共有する定期実行ジョブを組み合わせれば、推奨されたマイナーバージョンアップグレード に向けて事前に準備できます。ビジネス要件やリソースに合わせた追加の検証手順とリカバリー手順をあらかじめ用意しておけば、マイナーバージョンアップグレードでも本番に影響が出ないという確信を大きく高められます。\