ひえー
東京の同一リージョンなのにオハイオ経由は草。PaaSとジオDNSの組み合わせは罠すぎる。こういう泥臭い切り分けドキュメントはマジで助かるわ
planet scaleとfly.ioの環境の話なのに手元の再現は関係ないだろ。fly.ioでsshして確認しないと意味ない。何言ってんの
で、なんで位置の推定を間違うの？なんでそのIPなの？
何で推定間違うのか意味わかんないけど、そういう事例があるってのは勉強になった。何かの大きな改修と一緒に見つかると確かに切り分け難しくて大変そうだ
エッジ使ってないの？
分かった時気持ちよかっただろうなー。その脳汁で白米おかわりしながらこのエントリ書いてるんだろうな。
よくわからんけどFly.ioに割り当てられてるIPアドレスはまとめてアメリカ国内ってことになってんのかね
こんなん解決できんすげえ
こういうのの原因突き止めた時に、脳汁が吹き出る感覚あるよね。この感覚味わえるポジションの人は幸運だと思う。こういう作業を任せられるように頑張る価値がある。
へー
パッケージになってて外側からは気づきにく中身に原因を突き止め対策立てたという話かな。AI開発が進み不具合の原因追及が難しくなる今後を想像すると、「諦めて受け入れる、人間の追及コストが高い」になるかも。
35倍速くなったときの気分を味わってみたい。大変だったと思うけど。
こんな原因、思いつかない。よく見つけたなー。すごい。
へー、面白い
こういう仕事ばっかしててもなお、切り分けはもうほんと「なんで！？」の連続になるよ
“「直近のリリースと症状の時期が重なっている」ことは、因果の証拠にはならない”
この手のトラップは「特定のリージョンに負荷試験クライアント立てて特定のエッジロケーションに偏る」のが多いけど、リゾルバーが米国にあると認識ないと気が付かないよねえ
こんなことが起きるんか・・
結局、悪くなった契機となったのは、ジオDNSの結果が変わったということ？何もしてないのに壊れたのか、何かしたから壊れたのか。
DBのクラウドサービスがCDN経由の接続になっていて、Appサーバから見えるDNSリゾルバがなぜか海の向こうのものだったので海の向こうのエッジサーバが選択されて超遅くなったということらしい。
IPアドレスをIPと言う人はUSBメモリをUSBと言います
何故リニューアルで発生したのかは分からずじまい？最初にコードを疑ってるからインフラの構成は変わってないはずだよね？
Route 53のレイテンシベースルーティングで最寄りエッジの推定が罠だった件。
うーむ、なんかそれほど、すごい！って感じしないけどなぁ。。
“遅くなりだしたのがフルリニューアルの時期と被っていたこと” 胃が痛い
へー、おもしろい。
“同じ構成（ジオDNSで接続先が決まるマネージドサービス × PaaS）なら他社でも普通に起こり得る話なので、事例として共有します。”
よかった。なぜ推定を間違うのかが分からないのは自分だけじゃなかった。Fly.ioで名前解決するときは日本からでもUSのリゾルバに問い合わせてるってこと？ それともリゾルバは日本にあるけどUSにあるっぽい顔をしてる？
推測ではなく計測を行う事が解決の道だったという話ではあるが…。または、遅いときはまずトレース見ようねって話なのかもしれない。/ところで、AWSってジオDNSに偏った設計してるけど、理由はなんだろう…。
AWSに閉じた世界でもAmazon S3への通信がバージニア北部経由になってたとかあるあるのやつだ。
APIもDBも東京なのに、全クエリが太平洋横断していた話
ひえー
東京の同一リージョンなのにオハイオ経由は草。PaaSとジオDNSの組み合わせは罠すぎる。こういう泥臭い切り分けドキュメントはマジで助かるわ
planet scaleとfly.ioの環境の話なのに手元の再現は関係ないだろ。fly.ioでsshして確認しないと意味ない。何言ってんの
で、なんで位置の推定を間違うの？なんでそのIPなの？
何で推定間違うのか意味わかんないけど、そういう事例があるってのは勉強になった。何かの大きな改修と一緒に見つかると確かに切り分け難しくて大変そうだ
エッジ使ってないの？
分かった時気持ちよかっただろうなー。その脳汁で白米おかわりしながらこのエントリ書いてるんだろうな。
よくわからんけどFly.ioに割り当てられてるIPアドレスはまとめてアメリカ国内ってことになってんのかね
こんなん解決できんすげえ
こういうのの原因突き止めた時に、脳汁が吹き出る感覚あるよね。この感覚味わえるポジションの人は幸運だと思う。こういう作業を任せられるように頑張る価値がある。
へー
パッケージになってて外側からは気づきにく中身に原因を突き止め対策立てたという話かな。AI開発が進み不具合の原因追及が難しくなる今後を想像すると、「諦めて受け入れる、人間の追及コストが高い」になるかも。
35倍速くなったときの気分を味わってみたい。大変だったと思うけど。
こんな原因、思いつかない。よく見つけたなー。すごい。
へー、面白い
こういう仕事ばっかしててもなお、切り分けはもうほんと「なんで！？」の連続になるよ
“「直近のリリースと症状の時期が重なっている」ことは、因果の証拠にはならない”
この手のトラップは「特定のリージョンに負荷試験クライアント立てて特定のエッジロケーションに偏る」のが多いけど、リゾルバーが米国にあると認識ないと気が付かないよねえ
こんなことが起きるんか・・
結局、悪くなった契機となったのは、ジオDNSの結果が変わったということ？何もしてないのに壊れたのか、何かしたから壊れたのか。
DBのクラウドサービスがCDN経由の接続になっていて、Appサーバから見えるDNSリゾルバがなぜか海の向こうのものだったので海の向こうのエッジサーバが選択されて超遅くなったということらしい。
IPアドレスをIPと言う人はUSBメモリをUSBと言います
何故リニューアルで発生したのかは分からずじまい？最初にコードを疑ってるからインフラの構成は変わってないはずだよね？
Route 53のレイテンシベースルーティングで最寄りエッジの推定が罠だった件。
うーむ、なんかそれほど、すごい！って感じしないけどなぁ。。
“遅くなりだしたのがフルリニューアルの時期と被っていたこと” 胃が痛い
へー、おもしろい。
“同じ構成（ジオDNSで接続先が決まるマネージドサービス × PaaS）なら他社でも普通に起こり得る話なので、事例として共有します。”
よかった。なぜ推定を間違うのかが分からないのは自分だけじゃなかった。Fly.ioで名前解決するときは日本からでもUSのリゾルバに問い合わせてるってこと？ それともリゾルバは日本にあるけどUSにあるっぽい顔をしてる？
推測ではなく計測を行う事が解決の道だったという話ではあるが…。または、遅いときはまずトレース見ようねって話なのかもしれない。/ところで、AWSってジオDNSに偏った設計してるけど、理由はなんだろう…。
AWSに閉じた世界でもAmazon S3への通信がバージニア北部経由になってたとかあるあるのやつだ。