集中アクセスに強い「tenki.jp」、なぜDDoS攻撃にあっさり敗れたのか？

DDoS攻撃によって2週間もつながりにくい状況がtenki.jpに発生した。このような不具合を繰り返さないためには短期的な対策だけでは足りない。このような判断から中期的、長期的な対策を立てて成功しつつあるという。どのように取り組んだのだろうか。

[高橋睦美，キーマンズネット]

　猛暑や線状降水帯によるゲリラ豪雨といった異常気象が増加する中、天気予報が果たす役割はますます重要になってきた。日本気象協会とALiNKインターネットが共同で運営する天気予報専門メディア「tenki.jp」はニーズに応えるため、Webやアプリケーションを通して天気や防災に関する情報を提供している。

　しかし2025年1月、tenki.jpは断続的なDDoS攻撃を受けて、アクセスしにくい状態が約2週間にわたって続いてしまった。一体どのような方針で解決策を探り、この緊急事態を乗り切ったのだろうか。ALiNKインターネットの森島昌洋氏（執行役員兼サービス統括部部長）が「AWS Summit Japan」（2025年6月25〜26日、千葉県開催）のセッション「tenki.jp に学ぶセキュリティインシデント発生時の即応に必要な事業判断とエッジサービス活用」で語った内容を基に紹介する。

びくともしなかったtenki.jpが落ちたDDoS攻撃

　tenki.jpは、2024年度の一年間で約60億PVのトラフィックを集める、国内有数の天気予報専門メディアだ。「天気予報を見るだけでなく、それを基に自分の今日の予定を良い方向に持っていけるような態度変容を提供できるサービス」（森島氏）を目指して提供している。

　近年、異常気象や群発地震などが起こると、まずスマートフォンで情報を確認するのではないだろうか。tenki.jpではそうした状況でも大規模なトラフィックをさばけるようにサービス構築に努めてきた。だが、森島氏は「そうした実績があってもなお、昨今のDDoS攻撃は対応が非常に困難でした」と振り返った。

　複数のコンピュータやbotネットを操って特定のサーバやネットワークに大量のトラフィックを送りつけて「まひ」させ、正常にサービスを提供できなくしてしまうのがDDoS攻撃だ。tenki.jpも、過去にたびたびDDoS攻撃を受けてきたという。

ALiNKインターネットの森島昌洋氏

　だがtenki.jpはそもそも、台風接近時や地震発生のたびに通常のユーザーが大挙して押し寄せるサービスだ。「1時間あたり50〜150万セッション程度のトラフィックを日常的に処理しており、警報級の台風接近時にはじわじわと高負荷が続くことも当たり前です。DDoS攻撃を受けても気付かないこともあるほどで、サービスに影響することはこれまでほとんどありませんでした」（森島氏）

　そうした自信が崩れたのが、2025年1月5日から始まったDDoS攻撃だった。最大で60Gbps超の攻撃を受け、これまで震災や台風接近でもびくともしなかったtenki.jpが止まってしまった。当初はあまり悲観してなかったそうだが、その思いはすぐに変った。

　「最初は高負荷の攻撃でも断続的に起こっていたので、何とか乗り切れるのではないかと思っていました。しかし、そのうちtenki.jpのサーバを格納していたデータセンターそのものの運用に影響を与えるレベルになってしまい、RTBH（Remote Triggered Black Hole）でtenki.jpへのアクセスを全てブラックホールにリダイレクトする運用になってしまいました」（森島氏）

　こうして8時間ほどかけて事態を収束させたが、その間、tenki.jpにアクセスしづらい状況が続いてしまった。折しも、東北北部では豪雪で天気情報のニーズが高まっている中でこうした事態が起こってしまい、身近な人からも、またネット上でも「tenki.jpは大丈夫か」といった声を耳にして、あらためて「社会インフラの一つ」を担っている責任感を痛感したという。

巨大なアクセスだけではない現在のDDoS攻撃

　このDDoS攻撃には幾つかの特徴があった。1つ目は、2週間ほど断続的にしつこく攻撃が続いたことだ。手を打って攻撃が引いていき「晴れたな、もう大丈夫だな」と思ったらまた豪雨のようにトラフィックが襲ってくる事態が続いた。あらためて「昨今の攻撃が非常に執拗（しつよう）になり、長期化していることを実感しました」（森島氏）

複雑化する現在のDDoS攻撃（提供：ALiNKインターネット）

　2つ目は、手法の複雑化・巧妙化だ。攻撃先のIPアドレスが次々移り変わるのはもちろん、攻撃元のIPアドレスも頻繁に変化していった。「学習型IPフィルタリングをすることで多少のDDoS攻撃ならはじけるはずですが、あまりにも攻撃元が複数、かつ多種多様だったため、フィルタリングが追い付きませんでした」（森島氏）

　また攻撃手法もさまざまだった。まずリフレクション攻撃を仕掛けてきて、tenki.jpが対応すると次はSYN Floodに切り替える――という具合に、次々に手法を切り替えてくるため、その意味でも終わりが見えなかったという。

　特に印象に残ったのは、攻撃トラフィックの流量が動的に変化していったことだ。「いきなり大きな負荷を与えるのではなく、段階的に上げていったり、ある日突然スパイクさせるといったりした変化がありました」。当初の流量に基づいて施した応急処置では次の攻撃に対応できなくなるため、「初動の判断が非常に困難でした」と同氏は振り返った。

「ソリューションを入れて終わりではない」と長期目標を立てて対応

　DDoS攻撃にしても他のセキュリティインシデントにしても、発生直後の社内はカオス状態に陥る。その中で、特に事業・経営サイドからエンジニアにぶつけられる代表的な言葉は「早く何とかしろ」ではないだろうか。

　だが森島氏は今回の経験も踏まえて、「『何とかしろ』と言われたエンジニアは怒っていいと思いますし、『何とかしろ』としか言えないビジネスサイドは学ぶ必要があります」と述べた。そしてビジネスサイドには短期的な対応だけでなく、中期、長期的な対応を考えていくことが求められるとした。

　tenki.jpの場合、DDoS攻撃を受けてまず手をつけたのは「通常稼働の回復」という短期目標だった。効果は問わず、とにかく「すぐできること」を全てやろうという方針で対策を打ったものの、「結果的には不十分で、結果的に2週間の断続的な障害に至りました」（森島氏）

　tenki.jpではこうした事態を踏まえ、「未発事象も視野に入れ防御策を導入する」という中期目標と、「オペレーション改善の定期実施」という長期目標を立てて対策を進めていった。

短期、中期、長期でDDoS攻撃に対応した（提供：ALiNKインターネット）

　このうち中期目標を実現する手段が「最適な新しいサービス」の導入で、その過程でAmazon Web Services（AWS）のソリューションを導入することに決定した。

　ただ、注意すべき点がある。「ソリューションを入れれば全て終わりではありません。その後も攻撃は継続的にありますし、手法もどんどん進化していきます。ですから私たちも学びを蓄積し、実装に変えていかなければなりません」（森島氏）

　そのために不可欠なのが長期目標で立てた継続的なオペレーション改善だ。これを実現するには一握りの関係者だけではなく、エンジニアやパートナーなど広く関係者の間で「一度対策して終わりではない」という意識を共有し、合意をとることが重要だとした。さもなければ、周りから「まだ事故対応をやっているのか」と懐疑的な目で見られ、継続的な対応が困難になってしまうという。

AWSのエコシステムも生かしながら、サービス特性に合わせた対策を迅速に導入

　中期目標の実現に話を戻すと、tenki.jpではCDN（Content Delivery Network）やWAF（Web Application Firewall）といったさまざまなソリューションを比較して、自社サービスの特性や要件に見合ったものを選定、導入していった。

　これは、他のソリューションの場合でも同様だ。だが、そのプロセスの中で頭を悩ませることは多い。コストや柔軟性、運用負荷、サポート体制など、選定基準を挙げていけばきりがないからだ。

　そんな中から今回森島氏らは、「今動いているシステムに問題なくアドオンできるよう容易にオペレーションでき、かつ導入検証がしやすいこと」「その後の継続改善をさせる『エコシステム』の仕組みがあること」の2つのポイントに絞って選定を進め、最終的に「Amazon CloudFront」と「AWS WAF」を導入した。

　tenki.jpのサービスは特殊だという。災害発生時などに押し寄せる大量のアクセスを処理できるだけの「効率性」と、刻々と変化していく天気情報を高頻度で反映できる「更新性」という、2つの相反する要素が強く求められるからだ。それを、通常の天気予報や雨雲レーダー、地震速報といったコンテンツの特性に合わせ、「ピーキー」に、いわば秘伝のタレ的に設計している。

　「このように多様性に飛んだインフラに対し、システムを停止せず、特性に合わせた柔軟な機能やルール設定ができ、ロールバックが簡単で、段階的に実装しながら本番環境で検証ができるようなものを入れてください――こう言われてエンジニアも困っただろうと思います。こうした要件に応えてくれたのがAmazon CloudFrontとAWS WAFでした」（森島氏）

　導入の結果、DDoS攻撃への耐性は格段に上がった。導入翌月に再度、30分間で数百万リクエスト規模のDDoS攻撃を受けたが、「このときは支障なくサービスを継続できました」と同氏は胸を張った。

AWSのサービスを採用したことでDDoS攻撃をうまく防御できた（提供：ALiNKインターネット）

継続的なチューニングは効果的だったのか

　だがそれを可能にしたのは、ソリューションそのものの優秀さだけではない。運用後もPDCAサイクルを回し、継続的にチューニングを実施してきたからだという。

　「導入当初はAWSのマネージドルールをベースにしてともかく立ち上げ、その上でサービスの特性に合わせてカスタムルールを追加していきました。そして、追加したルールがどのように動いたのかを、『Amazon CloudWatch』を用いてひたすらログをモニタリングして確認し、カスタムルールを最適化していきました」（森島氏）。このサイクルを繰り返すことで、防御はもちろん、コストやパフォーマンス、システム負荷を最適な状況に保っているという。

　さらに、あらかじめ設定した予算額と実際の支出額をほぼリアルタイムにモニタリングできる「AWS Budget Alarm」とWebアプリケーションに対するbotからの不要なトラフィックを検出して、ブロックしたり、制限したりする「AWS WAF Bot Control」の状況を見比べた。比較しながらコントロールルールを最適化することで、費用対効果の低いルールは外し、逆に攻撃が集中している部分についてはコストをかけてでもルールを追加するという具合にメリハリを効かせ、サービスの特性に合わせた防御策を実現した。

　こうした日々のブラッシュアップを実現できている要因として、AWSのエコシステムの力が大きいと森島氏は述べた。

　コミュニティーに蓄積された豊富な事例やノウハウ、周辺ツールや管理機能、そして充実したナレッジ・サポートを活用しながら対策を進めているという。加えて、それぞれに強みを持つAWSパートナーの力を借りることで、自分たちに適した対策の実践に専念できているとした。tenki.jpの場合、AWSのアドバンストティアサービスパートナーの技術支援を得ることで、「導入決定後、10日強で本環境への実装までたどり着きました」（森島氏）

　森島氏は最後に、日々DDoS攻撃が進化している中、不幸にしてインシデントが起きたとしても「ビジネスサイドは判断をエンジニアサイドに任せっきりにしてはいけません。エンジニアサイドの取り組みを整理し、ビジネスとしてどこまで飲み込むのかジャッジを下し、事業を安定的に運用するための決断を下すのがビジネスサイドの役割です」と述べ、そのために常日頃からビジネスサイドも知見を蓄積すべきだと呼び掛けた。

　さらに、そうして下した判断を実現していく上で、AWSのソリューションには技術的優位性だけでなく、「ビジネスサイドの判断を支援でき、また長く安定してサービスを続けていくのに必要なミドルウェアや監視ツール、ナレッジコミュニティーやパートナーといった生態系があることが最大の強みだと感じます」と評価した。

　そして、「一度はサービス障害を起こしてしまいましたが、災い転じて、ではありませんですが、AWSのソリューションを継続的に運用することで、皆さまの安心を守るサービスとして今後も進化を続け、新しい価値を届けていきたいと思います」と宣言し、講演を終えた。