Google Cloud kesinti raporu – 2025-06-13
(status.cloud.google.com)- 12 Haziran 2025’te Google Cloud, Google Workspace ve Google Security Operations’ta harici API isteklerinde 503 hataları arttı ve dünya genelindeki müşterileri etkiledi
- Service Control’deki yeni kota politikası kontrolü, boş alanlar içeren politika verileriyle karşılaşınca null pointer kaynaklı bir çökme döngüsüne yol açtı; bu yol rollout sırasında çalıştırılmamıştı
- Politika değişikliği regional Spanner tablolarından saniyeler içinde dünya geneline kopyalanınca, her region’daki Service Control dağıtımı aynı hata yoluna girdi ve olay küresel kesintiye dönüştü
- SRE ekibi 2 dakika içinde müdahaleye başladı, 10 dakika içinde nedeni belirledi ve yaklaşık 40 dakika içinde red-button rollout’unu tamamladı; ancak us-central1’in toparlanması en fazla yaklaşık 2 saat 40 dakika sürdü
- Tekrarı önleme adımları Service Control değişikliklerinin dondurulmasına, feature flag’lerin varsayılan olarak kapalı olmasına, global replikasyon verilerinin kademeli yayılmasına, hata işleme ve rastgele üstel backoff iyileştirmelerine odaklanıyor
Kesinti kapsamı ve zaman çizelgesi
- Google Cloud, Google Workspace ve Google Security Operations ürünlerinde harici API isteklerindeki 503 hatalarının artması müşterileri etkiledi
- Başlıca zamanların tümü US/Pacific saat dilimine göredir
- Kesinti başlangıcı: 12 Haziran 2025 10:49
- us-central1 hariç tüm region’larda hafifletme: 12:48
- Kesinti bitişi: 13:49
- Toplam süre: 3 saat
- Etki kapsamı: Global
- Müşteriler, etkilenen servislerde aralıklı API ve kullanıcı arayüzü erişim sorunları yaşadı
- Mevcut streaming ve IaaS kaynakları etkilenmedi
Service Control’ün üstlendiği kontrol yolu
- Google ve Google Cloud API’leri, Google API yönetim ve kontrol düzlemi üzerinden sunulur
- Bu yönetim ve kontrol düzlemi her API isteği için şunları kontrol eder
- İsteğin yetkilendirilmiş olup olmadığı
- Politika ve kota gibi kontrollerden geçip endpoint’e gidip gidemeyeceği
- Politika kontrol sisteminin temel binary’si Service Control’dür
- Service Control, region bazlı bir servistir ve kota ile politika bilgilerini okuyan regional datastore kullanır
- Bu datastore’un metadatası, Google Cloud ve müşterilerin kota politikası yönetimi için neredeyse anında dünya geneline replike edilir
Doğrudan neden: boş politika alanı ve null pointer
- 29 Mayıs 2025’te, ek kota politikası kontrolleri için Service Control’e yeni bir özellik eklendi
- Kod değişikliği ve binary release’i region bazlı rollout’tan geçti; ancak başarısız olan kod yolu yalnızca belirli bir politika değişikliği olduğunda çalıştığı için rollout sırasında doğrulanmadı
- Sorunlu kodda ilgili politika sağlama yolunu kapatan bir red-button vardı, ancak uygun hata işleme ve feature flag koruması yoktu
- Null pointer uygun şekilde işlenmedi ve Service Control binary’sinin çökmesine yol açtı
- Google, bunun feature flag ile korunmuş olması halinde önce iç projelerde, ardından region bazında kademeli olarak etkinleştirilerek sorunun staging’de yakalanacağını belirtti
Küresel yayılma süreci
- 12 Haziran 2025’te yaklaşık 10:45 PDT’de, Service Control’ün politikalar için kullandığı regional Spanner tablosuna bir politika değişikliği eklendi
- Bu politika verisi, kasıtsız olarak boş alan içeriyordu
- Kota yönetimi global ölçekte çalıştığı için ilgili metadata saniyeler içinde dünya geneline replike edildi
- Her region’daki Service Control, regional datastore’daki politika için kota kontrolü yaparken boş alanı okudu ve null pointer ile karşılaşan kod yolu çalıştı
- Sonuç olarak her region’daki dağıtımda binary çökme döngüsüne girdi
Müdahale ve kurtarmadaki gecikme
- SRE ekibi, kesinti başlangıcından sonraki 2 dakika içinde sınıflandırma ve müdahaleye başladı
- 10 dakika içinde kök nedeni belirleyip red-button uygulamasına geçti
- Red-button, kesinti başlangıcından yaklaşık 25 dakika sonra rollout’a hazır hale geldi
- Kesinti başlangıcından sonraki 40 dakika içinde red-button rollout’u tamamlandı ve küçük region’lardan toparlanma sinyalleri gelmeye başladı
- us-central1 gibi büyük region’larda Service Control işleri yeniden başlatılırken bağımlı altyapıda, özellikle Spanner tablolarında herd effect yarattı ve aşırı yüke neden oldu
- Service Control’de bunu önlemek için uygun rastgele üstel backoff uygulanmamıştı
- us-central1’de iş oluşturma throttling ile sınırlandırıldı ve trafik multi-regional database’e yönlendirilerek yük azaltıldı; tam çözüm en fazla yaklaşık 2 saat 40 dakika sürdü
- Daha sonra Service Control ve API serving tüm region’larda tamamen toparlandı
- İlgili Google ve Google Cloud ürünleri, mimarilerine bağlı olarak bazıları daha uzun sürecek şekilde sırayla toparlandı
Durum sayfası ve müşteri iletişimi
- İlk Cloud Service Health kesinti raporu, çökmelerin başlamasından yaklaşık 1 saat sonra yayımlandı
- Gecikmenin nedeni, bu kesinti nedeniyle Cloud Service Health altyapısının kendisinin devre dışı kalmış olmasıydı
- Bazı müşterilerde Google Cloud üzerinde çalışan izleme altyapısı da başarısız oldu; bu yüzden kesinti sinyallerini veya iş ve altyapı üzerindeki etki kapsamını belirleyemediler
- Google, müşterilerin soruna yanıt vermek, sistemlerini yönetmek ve kendi müşterilerini desteklemek için ihtiyaç duyduğu bilgileri daha hızlı alabilmesi adına otomatik ve manuel dış iletişimi iyileştireceğini belirtti
- Google Cloud ve temel izleme ürünleri devre dışı kalsa bile izleme ve iletişim altyapısının müşterilere hizmet vermeye devam etmesini sağlayacağını belirtti
Acil aksiyonlar ve tekrarı önleme planı
- Kurtarmanın hemen ardından Service Control stack değişiklikleri ve manuel politika push’larının tamamı donduruldu
- Google, aşağıdaki aksiyonları önceliklendirip güvenli şekilde tamamlayacağını belirtti
- Service Control mimarisini modülerleştirerek özellikleri izole etmek ve ilgili kontroller başarısız olsa bile API isteklerini işlemeye devam edebilecek fail open bir yapıya geçirmek
- Dünya genelinde replike edilen verileri tüketen tüm sistemleri denetlemek
- Global ölçekte neredeyse anlık tutarlılık gerektiren iş ihtiyaçları olsa bile, veri replikasyonunu sorunların doğrulanması ve tespiti için yeterli süre tanıyacak şekilde kademeli yaymak
- Kritik binary değişikliklerinin tümünü feature flag ile korumak ve varsayılan olarak devre dışı bırakmak
- Hataları doğru işlemek ve gerektiğinde fail open yapabilmek için statik analiz ve test uygulamalarını iyileştirmek
- Sistemlerin rastgele üstel backoff kullanıp kullanmadığını denetlemek ve garanti altına almak
- Müşteri iletişimini iyileştirmek
- Google Cloud ve temel izleme ürünlerinde kesinti sırasında da izleme ve iletişim altyapısının çalışmasını sürdürmek
Etkilenen servisler ve kalan etkiler
- Çok sayıda Google Cloud ürünü etkilendi; listede Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, Cloud Run, Google BigQuery, Vertex Gemini API, Apigee, Google Cloud Bigtable, Cloud Functions, Cloud Load Balancing, Cloud Firestore, Cloud Logging, Cloud Spanner, Google App Engine, Google Cloud Console, Google Compute Engine, Cloud SQL, Cloud Pub/Sub, Persistent Disk, Google Security Operations ve diğerleri yer aldı
- Google Workspace ürünlerinden AppSheet, Gmail, Google Calendar, Google Drive, Google Chat, Google Voice, Google Docs, Google Meet, Google Cloud Search ve Google Tasks etkilendi
- Bazı ürünlerde ana kesinti hafifletildikten sonra da kalan etkiler sürdü
- Google Cloud Dataflow’da backlog kademeli olarak eridi ve us-central1’de gecikme devam etti
- Vertex AI Online Prediction’da Model Garden’daki bazı modellerde yüksek 5xx hataları sürdü; daha sonra 18:18 PDT itibarıyla tamamen toparlandı
- Personalized Service Health’te güncelleme gecikmeleri yaşandı ve müşterilere Cloud Service Health panosunu kullanmaları önerildi
1 yorum
Bu, GN+ olmayan sürüm yazısının bağlantısıdır.