LASSIC Media らしくメディア

システム間の連携で、あるメッセージだけが何度処理しても失敗し続ける——。そんなとき、その一件を延々と再試行し続けると、後ろに並んだ正常なメッセージまで処理が滞り、連携全体が詰まってしまいます。この「処理できない一件」をいったん脇へ避けておく受け皿が、デッドレターキュー（DLQ）です。

非同期のメッセージ連携やイベント駆動の仕組みでは、DLQは欠かせない仕組みとして広く使われています。ただ、「とりあえず用意したものの、溜まったまま放置されている」というつまずきも起こりがちです。本記事では、システムの設計・運用にたずさわる情報システム部門の担当者に向けて、デッドレターキューとは何か、近い仕組みとの違い、つまずきやすい点、そして運用と外注の勘所を整理します。

デッドレターキューとは——リトライ・通常キューとの違い

デッドレターキュー（DLQ：Dead Letter Queue）とは、通常のキューで処理に失敗し続けたメッセージを、退避させておくための専用のキューを指します。「デッドレター」は、宛先に届かなかった郵便物になぞらえた呼び名です。メッセージキューを使った連携では、送り手が投入したメッセージを、受け手が順に取り出して処理します。たいていはうまくいきますが、データの不備や連携先の不調などで、どうしても処理できないメッセージが混じることがあります。そうしたメッセージを本流から切り離し、いったん保管しておくのがDLQの役割です。

混同されやすいのが、リトライ（再試行）や通常のキューとの関係です。処理に失敗したメッセージは、まず何回か再試行されるのが一般的です。DLQは、その再試行を尽くしても、なお処理できなかったメッセージの行き先にあたります。リトライやサーキットブレーカーといった障害対策が「もう一度試す」仕組みだとすれば、DLQは「試しても駄目だったものを、あきらめて脇へ避ける」仕組みです。

また、通常のキューが「これから処理する順番待ちの列」であるのに対し、DLQは「処理できずに取り残されたものの置き場」だという違いがあります。順番を待っているのか、行き詰まって避けられたのか——立ち位置がまったく別物です。この区別を押さえておくと、DLQに何を期待すべきかがはっきりします。

なぜ必要なのか

DLQが求められる背景には、「処理できない一件」が全体を巻き込んでしまう、という問題があります。もしDLQがなければ、失敗したメッセージはどうなるでしょうか。多くの場合、成功するまで、あるいは延々と、再試行が繰り返されます。データそのものが壊れているようなメッセージは、何度試しても成功しないものです。こうしたメッセージは毒メッセージ（ポイズンメッセージ）とも呼ばれ、放っておくと再試行のループから抜け出せなくなります。

問題は、その一件だけにとどまらない点です。受け手が一件の失敗に付きっきりになると、後ろに並んだ正常なメッセージの処理が進まず、連携全体が遅れます。無駄な再試行が連携先に負荷をかけ、状況を悪化させることもあるのです。DLQは、こうした行き詰まりを断ち切るために、失敗し続けるメッセージを本流から抜き取り、脇へ避けます。これにより、正常なメッセージの流れを守りつつ、避けたメッセージはあとから落ち着いて調べられるのです。つまりDLQは、処理を止めないための逃がし弁であり、同時に、失敗を握りつぶさず後で向き合うための記録でもあるのです。だからこそ、非同期の連携には、原則としてDLQのような受け皿を用意しておくことが求められます。

DLQの仕組みと流れ

DLQがどう働くのか、メッセージが失敗してから避けられるまでの流れを追うと、仕組みがつかめます。全体像を押さえておくと、自社の連携でどこに備えが要るかが見えてくるはずです。順を追って見ていきましょう。この流れを図にすると、次のとおりです。

まず、受け手がメッセージの処理に失敗すると、そのメッセージはすぐには捨てられず、一定の回数まで再試行されます。次に、あらかじめ決めた再試行の上限を超えると、そのメッセージは通常のキューには戻されず、DLQへと移されます。ここで本流から切り離されるわけです。DLQへ移ったメッセージは、そのまま放置するのではなく、なぜ処理できなかったのかを調査します。原因が分かって直せるものであれば、修正したうえで通常のキューへ戻し、もう一度処理させるわけです。この戻す操作を、再投入（リドライブ）と呼ぶこともあります。一方、そもそも不要だったり、直しようがなかったりするメッセージは、記録を残したうえで破棄するのが基本です。この一連の流れがあってはじめて、DLQは意味を持ちます。

つまずきやすい難所

DLQの導入と運用には、あらかじめ想定しておきたい難所があります。踏まえておくと、「置き場を作ったのに、ただ溜まっていくだけ」という事態を避けやすくなります。

とりわけ多いのが、放置です。DLQは用意しただけでは意味がなく、そこにメッセージが溜まったことに気づき、中身を調べてはじめて役に立ちます。溜まりを見張る仕組みがないと、失敗が静かに積み上がり、あとで大きな取りこぼしとして発覚します。二つ目は、再試行の設計です。上限が少なすぎると、一時的な不調で回復するはずのメッセージまでDLQへ送ってしまいます。逆に多すぎると、毒メッセージがなかなか避けられず、詰まりが長引きます。三つ目は、再投入時の二重処理です。DLQから戻したメッセージが、実は一度は処理されていた、という場合、同じ処理が二度走って数字が狂うことがあります。これを防ぐには、同じメッセージを二度処理しても結果が壊れない冪等性の作りが前提になります。四つ目は、原因の記録不足です。なぜDLQに入ったのかという手がかりが残っていないと、調査に時間がかかります。いずれも、「避けること」だけでなく「そのあと向き合うこと」まで見据えると、避けやすくなる落とし穴です。

運用として回す勘所

DLQは、一度設定して終わりではなく、溜まったものに向き合い続ける運用があってはじめて機能します。仕組みとして定着させる勘所を整理しました。

鍵になるのは、DLQを「気づける」状態にしておくことです。件数を見張り、溜まったら通知が飛ぶようにしておけば、失敗が静かに積み上がる事態を防げます。そのうえで、入った原因を分類して記録しておくと、同じ失敗が繰り返されているのか、たまたまの一件なのかを見分けやすくなるはずです。再投入するときは、二度処理しても壊れない作りを前提に、落ち着いて戻す——この一連を運用として回すことで、DLQは単なる置き場から、失敗を取りこぼさず拾い上げる仕組みへと変わります。

外注時に確認しておきたい点

DLQの設計や運用を外部に委託する場合は、次の点を事前にすり合わせておくと、認識のずれを防ぎやすくなります。まず、再試行の回数や間隔、どの段階でDLQへ送るのかという方針です。ここは扱う業務やメッセージの性質で変わるため、委託先任せにせず一緒に決めておきたいところです。次に決めておきたいのが、溜まりに気づく仕組みになります。DLQの件数をどう見張り、誰にどう通知するのかを決めておかないと、置き場を作っても放置されがちです。

さらに、DLQに入ったメッセージへの対処の分担も決めておきたい点です。原因の調査や再投入の判断を、どこまで委託先に任せ、どこからは社内で行うのか——ここが曖昧だと、いざ溜まったときに対応が止まります。あわせて、再投入で二度処理しても壊れない作りになっているか、原因を追える記録が残る形かも、確認しておくとよいでしょう。DLQの用意だけを頼むのか、溜まったものに向き合う運用まで含めて依頼するのかを明確にしておくと、任せたあとのつまずきを抑えやすくなります。

まとめ：DLQで押さえる3つの視点

デッドレターキューは、再試行を尽くしても処理できなかったメッセージを脇へ避け、連携全体が詰まるのを防ぐ歯止めです。押さえておきたい視点は3つに整理できます。第一に、DLQはリトライを尽くした先の受け皿であり、順番待ちの通常キューとは立ち位置が異なると理解すること。第二に、壊れた一件が全体を巻き込むのを防ぐという役割を踏まえ、非同期の連携には受け皿を用意しておくこと。第三に、DLQは用意して終わりではなく、溜まりを監視し、原因を調べ、必要なら再投入する運用があってはじめて機能する——その際、二度処理しても壊れない作りが前提になる、という点です。この3点を踏まえておけば、「置き場は作ったのに、失敗が静かに溜まって取りこぼす」という事態を避けやすくなります。設計や運用に不安があれば、外部の手を借りるのも一つの選択肢です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　参考：Amazon Web Services「Amazon SQS デッドレターキュー」（https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html）。DLQの一例として。実際の挙動や用語は利用する製品により異なります。

Tweet