コンテンツに移動
データベース

Spanner 向けロックとトランザクションの分析情報のご紹介: 事前構築済みのダッシュボードでロックの競合のトラブルシューティングを行う

2022年10月27日
Google Cloud Japan Team

※この投稿は米国時間 2022 年 10 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

開発者や DevOps エンジニア、データベース管理者は通常、データベースのロック問題に対処する必要があります。クエリにより行がロックされると、ラグが発生し、アプリケーションの速度が低下して、ユーザー エクスペリエンスの低下につながる場合が多くあります。これにともない、本日 Cloud Spanner 向けのロックとトランザクションの分析情報がリリースされたことをお知らせいたします。この新しい可視化ツールのセットにより、開発者およびデータベース管理者は Spanner 上のロックの競合の問題を迅速に診断できます。

アプリケーションの速度低下がみられる場合、一般的にロックの競合が問題である可能性があります。これは、複数のトランザクションによって同じ行が変更されようとしたときに発生します。ロックの競合をデバッグするには、ロックの競合が生じているトランザクションがある行範囲と列を特定する必要があるため、容易ではありません。このプロセスは、視覚的なインターフェースがない場合、面倒で時間がかかることがあります。現在、Google はお客様が抱えるこのような問題の解決に取り組んでいます。

ロックとトランザクションの分析情報では、事前構築済みのダッシュボードを提供することで、ロック待機時間が最も長い行範囲の検出、その行範囲で読み取りまたは書き込みを行っているトランザクションの発見、レイテンシが最大でロックの競合を引き起こしているトランザクションの特定が容易になります。

今年初め、Google はクエリのパフォーマンス問題をデバッグする Query Insights をリリースしました。ロックとトランザクションの分析情報とともに使用することで、これらの機能は開発者にとって使いやすいオブザーバビリティ ツールとなり、問題のトラブルシューティングおよび Spanner データベースのパフォーマンスの最適化に役立ちます。ロックとトランザクションの分析情報は追加料金なしで利用可能です。

Kohl’s のスタッフ ソフトウェア エンジニアで理系修士号を持つ Dominick Anggara 氏は、次のように述べています。「ロックの分析情報は、通常数時間はかかるロックの競合のデバッグに役立つでしょう。ユーザーは全体像を確認して、簡単に関連付けを行い、特定のトランザクションを絞り込めます。これがこのツールの強力な点です。本番環境で使用するのが本当に楽しみです。」

ロックの問題が発生する理由

ほとんどのデータベースではデータをロックして、他のトランザクションがデータを同時に変更できないようにすることで、データの整合性を維持しています。お客様がデータを変更するためにデータにアクセスした場合、変更中はロックによって他のトランザクションがそのデータにアクセスできなくなります。しかし、データがロックされると、他のタスクはそのデータへのアクセスを待機するため、アプリケーションのパフォーマンスにマイナスの影響を与える可能性があります。

Cloud Spanner は Google Cloud の水平スケーリングが可能なフルマネージド リレーショナル データベース サービスで、最も厳格な同時実行制御を保証するため、お客様はデータの整合性を気にすることなく、トランザクションのロジックに集中できます。お客様にご安心いただきながら、複数の同時実行トランザクションの整合性を確保するために、Spanner では行全体のレベルではなくテーブルのセルレベル(行および列の粒度)で、共有ロックと排他ロックを組み合わせて使用しています。Spanner におけるロックモードの種類についてはドキュメントをご覧ください。

事前構築済みのダッシュボードを使った視覚的な手順

ロックとトランザクションの分析情報を使うことで、開発者はレイテンシ問題の検出からロックの競合の診断へスムーズに進み、最終的にロックが競合しているトランザクションを特定できます。ロックの競合を引き起こしているトランザクションを見つけたら、各トランザクション内でその原因となっている問題の特定を試みることができます。

お客様は、簡単な手順で、アプリケーションの速度低下の原因がロックの競合であることの確認、ロック待機時間が最も長い行範囲および列とその行範囲をロックしているトランザクションとの関連付け、レイテンシが最大のトランザクションの特定、ロックが競合しているトランザクションの分析を迅速に行うことができます。例を見ていきましょう。

アプリケーションの速度低下を診断する

この手順は、Google Cloud Monitoring でレイテンシ(api/request_latencies)があるしきい値を超えた場合のアラートを設定するところから始まります。アラートは、このしきい値を超えると、「Monitoring」ダッシュボードへのリンクとともに、メール通知アラートでお客様に通知されるように構成できます。

このアラートを受け取ったら、メール内のリンクをクリックして、「Monitoring」ダッシュボードに移動します。読み取り / 書き込みレイテンシが急増していて、CPU 使用率に急上昇がみられず、1 秒あたりのスループットかオペレーション(またはその両方)が低下している場合、根本的な原因はロックの競合である可能性があります。このような指標のパターンの組み合わせは、ワークロードは同じであるにもかかわらず、トランザクションが同じセルで競合しているために、システムによりロックされていることを示す強いシグナルであることがあります。以下のスクリーンショットでは、5:45 PM と 6:00 PM の間に急増がみられます。この原因は、新しいアクセス パターンを導入したと考えられる新しいアプリケーション コードのデプロイである可能性があります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_spanner_insights.max-2000x2000.jpg

次に、このアプリケーションの速度低下の原因が実際にロックの競合であることを確認します。ここで、ロックの分析情報の出番です。このツールにアクセスするには、Cloud コンソールの Spanner インスタンス ビューの左側にあるナビゲーションで [ロックの分析情報] をクリックします。ここで、最初に表示されるグラフはロック待機の合計です。このグラフの対応する時間枠で対応する急増がみられる場合、アプリケーションの速度低下の原因がロックの競合であることを確認できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_spanner_insights.max-2000x2000.jpg

行範囲、列、トランザクションを関連付ける

ロック待機時間の合計に急増がみられるデータベースを選択し、ドリルダウンすることでロック待機時間が最も長い行範囲を確認できます。ユーザーがロック待機時間の最も長い行範囲をクリックすると、右側のパネルが開きます。パネルには、読み取りや書き込みが行われた列、その行と列の組み合わせ(データベースのセル)で取得されたロックの種類、そのロックで競合していたトランザクションを表示するリンクなど、その行範囲でのロック リクエストのサンプルが表示されます。これによって行範囲、列、トランザクションを関連付けることが可能になり、次のセクションで説明するように、ロックの分析情報とトランザクション分析情報をシームレスに切り替えられるようになります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_spanner_insights.max-1300x1300.jpg

上述のスクリーンショットでは、5:53 PM にテーブルの最初の行範囲(order_item(82,12))が最も長いロック待機時間を示していることがわかります。ロックのサンプルの列に影響しているトランザクションを確認することで、詳細を調査できます。

ロックを引き起こしている書き込みのレイテンシが最も長いトランザクションを特定する

ロックの分析情報のページの [トランザクションの表示] をクリックすると、前のページ(ロックの分析情報)のロックのサンプルの列でフィルタした(レイテンシ)topN トランザクション テーブルが表示されたトランザクション分析情報のページに移動します。それによって、手順の前半で特定したロック(および行範囲)の観点で topN トランザクションを確認できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_spanner_insights.max-900x900.jpg

この例では、item_inventory._exists と item_inventory.count 列からの読み取りおよびその列への書き込みを行っている最初のトランザクションでレイテンシが最大になっており、このトランザクションがロックの競合を引き起こしているもののひとつである可能性があります。また、テーブルの 2 番目のトランザクションも同じ列から読み取りをしようとしており、平均レイテンシが高いため、ロックを待機している可能性があることがわかります。これらのトランザクションの両方を深く掘り下げて調査する必要があります。

トランザクションを分析してロックの競合を解決する

ロックを引き起こしているトランザクションを特定したら、そのトランザクションの状態をドリルダウンして、ロックの競合の根本的な原因を分析できます。

topN テーブルから特定のトランザクションのフィンガープリント ID をクリックし、トランザクションの詳細ページに移動すると、特定のトランザクションの時系列での指標(レイテンシ、CPU 使用率、実行回数、スキャンされた行数 / 返された行数)のリストが表示されます。
https://storage.googleapis.com/gweb-cloudblog-publish/images/5_spanner_insights.max-2000x2000.jpg

この例では、2 番目のトランザクションをドリルダウンした場合、このトランザクションは読み取りのみを行おうとしており、書き込みは行っていないことがわかります。定義上、(前のページの)topN トランザクション テーブルには、ロックされた読み取り / 書き込みトランザクションのみが表示されます。また、中断回数と総試行回数の比率(28 / 34)が非常に高いことから、ほとんどの試行が中断されていることもわかります。

問題の解決

このシナリオで問題を解決するには、このトランザクションを読み取り / 書き込みトランザクションから読み取り専用のトランザクションに変換することで、セルでロックされることを防ぎ、ロックの競合を減らして、書き込みのレイテンシを抑えられます。

このシンプルで視覚的な手順に沿うことで、お客様は Spanner 上でロックの競合の問題を簡単に検出、診断、解決できます。

アプリケーションの潜在的な問題を調べる場合や、アプリケーションを設計する際にも、データベース内のロックの競合の数を減らすためにこれらのベスト プラクティスを検討してください。

今すぐロックとトランザクションの分析情報を使ってみる

ロックとトランザクションの分析情報について詳しくは、こちらのドキュメントをご確認いただき、こちらの解説動画をご視聴ください。

ロックとトランザクションの分析情報はデフォルトで有効になっています。Spanner コンソールの左側のナビゲーションにある [ロックの分析情報] と [トランザクション分析情報] をクリックして、ロックの問題およびトランザクションのパフォーマンス指標の可視化を開始できます。

Spanner 初心者の方へ。90 日間の Spanner 無料トライアル インスタンスを作成しましょう。Spanner を無料で試すことができます

- プロダクト マネージャー Mohit Gulati

投稿先