Azure Synapse Analyticsのメンテナンス

IT

  • Azure Synapse Analyticsのメンテナンスについて
  • メンテナンスの影響
  • メンテナンスの通知
  • メンテナンスへの対処

本記事ではAzure Synapse Analyticsのメンテナンスについて解説します。

Azure Synapse Analyticsのメンテナンスについて

メンテナンスでは新機能、アップグレード、および修正プログラムのデプロイが行われます。

このメンテナンスは2種類が存在します。

  • 計画メンテナンス(定期的なソフトウェアのアップグレード)
  • 計画外メンテナンス(緊急で適用する必要のあるセキュリティかかわる更新)

計画的なメンテナンスは、あらかじめ設定したメンテナンススケジュール(曜日及び時間を指定)内で実施されます。

このメンテナンススケジュールの機能は、DW 500C 以上が対象となっており、DW400C以下の環境においては、使用できません。

計画外メンテナンスは突然実施される可能性があり、セキュリティ関する緊急度の高いメンテナンスなどは速やかに実施されます。

こちらはあらかじめ通知される場合もありますが、すべての通知が発行されない可能性があります。

メンテナンスの影響

メンテナンスの際には、アップデートの適用されたリソースへ環境を移動させるため、ハードウェア リソースの瞬間的切り替えが発生します。

このタイミングで行われていたログイン処理や、クエリ処理は接続エラーにより失敗する可能性があります。

しかし、Azure Synapse Analyticsでは既定ですべての環境で冗長構成が組まれているため、メンテナンスが発生しても、メンテナンス実施中すべて使用できなくなるわけではなく、ダウンタイムは実際にロールの変更が完了するまでのわずかな時間のみです。

PaaSサービスであるAzure Synapse Analyticsではセキュリティパッチの適用やバージョンアップなどはすべて自動で行われるため、ユーザーが管理する必要はありませんが、メンテナンスに伴うダウンタイムと上手く付き合っていく必要が非常に重要です。

メンテナンスの通知

DW400c以下のパフォーマンスレベルの場合、指定された時間外のメンテナンスについてサービス正常性の計画メンテナンスの通知で通知はされません。

すべてのメンテナンス イベントの 24 時間前に事前通知が発行されますが、DWC400c と下位層はその対象ではありません。

出典: Synapse SQL プールのメンテナンス スケジュール – Azure Synapse Analytics | Microsoft Docs

DW500以上の場合、すべてのメンテナンスイベント(指定された時間外含む)も通知されますが、

セキュリティ関連などの緊急メンテナンスが必要となった場合、メンテナンス通知が発行されない可能性あります。

メンテナンスへの対処

メンテナンスに伴う一時的なエラーについては下記2つの観点からの対処が推奨されています。

  • リトライロジックの実装
  • トランザクションを短くする

リトライロジックの実装

メンテナンスを含む接続エラーの影響を抑えるため再試行ロジックの実装が推奨されています。

エラーにより処理はキャンセルされロールバックされますが、多くの場合リトライで解決可能となるからです。

一時エラーの再試行ロジック

一時エラーが多少なりとも生じるクライアント プログラムは、再試行ロジックを組み込むことで堅牢性を高めることができます。 ご使用のプログラムがサード パーティのミドルウェアを介して SQL Database のデータベースと通信する場合、一時エラーに対応した再試行ロジックがそのミドルウェアに備わっているかどうかをベンダーに確認してください。

出典:一時的なエラーへの対応 – Azure SQL Database | Microsoft Docs

前述したとおり、実際のダウンタイムは多くの場合1分以内で終了しますが、切り替えに伴うフェールオーバーが実施されたタイミングで、実行中・未完了の処理はすべてキャンセルされ、ロールバックされますため、エラーを検出したら自動でリトライをする仕組みを構築することが推奨されています。

ただし、大規模な障害などにより長時間ダウンタイムが発生したり、クライアント側の設定の問題などにより、長時間にわたり接続に失敗する場合なども考えられるため、リトライは無限に行うのではなく、要件に合わせ、回数などを制限しておくことも重要です。

トランザクションを短くする

メンテナンスによる接続エラーの影響を抑えるため、メンテナンス中は極力処理を行わない、もしくはトランザクションの単位を小さく設計することが推奨されます。

トランザクションの単位を小さくしておくことで、接続エラーになったときに下記2点のメリットがあります。

  • 再実行するための時間短縮
  • ロールバックの時間短縮

一方、ロングトランザクションはダウンタイムの長期化につながる可能性があります。

なぜなら、長い時間実行していた処理が途中でエラーになった場合、その時間分の変更に対してロールバックする必要があり、データベースはリカバリ処理が完了しないと使用可能な状態とならないからです。

そのため、メンテナンス中は極力処理を行わない、もしくは処理を短くするようにしましょう。

メンテナンス ウィンドウの長さは 3 ~8 時間ですが、これは、データ ウェアハウスがこの期間オフラインになることを示すわけではありません。 メンテナンスはそのウィンドウ内の任意の時点で発生する可能性があり、その期間中、サービスがデータ ウェアハウスに新しいコードをデプロイするときに最大5 ~6 分続く1 回の切断を予測しておく必要があります。DW400c 以下では、メンテナンス ウィンドウ内のさまざまな時点で接続が複数回にわたり短期間失われることがあります。 メンテナンスが開始されると、アクティブなセッションがすべて取り消され、コミットされていないトランザクションはロールバックされます。 インスタンスのダウンタイムを最小化するために、選択したメンテナンス期間の前に、長時間実行されるトランザクションがデータ ウェアハウスにないことを確認してください。

出典:Synapse SQL プールのメンテナンス スケジュール- Azure Synapse Analytics | Microsoft Docs

 まとめ

PaaSサービスであるAzure Synapse Analyticsではセキュリティパッチの適用やバージョンアップなどはすべて自動で行われる一方、メンテナンスに伴うダウンタイムをコントロールすることが難しくなります。

そのため、メンテナンスに伴う一時的なエラーについては下記2つの観点からの対処を実施しましょう。

  • リトライロジックの実装
  • トランザクションを短くする

参考