Gerçek dünya için IoT tasarlamak: güvenilmez ağlar, OTA ve güvenebileceğiniz veri

Kısa cevap: IoT sistemlerinde veri, saha cihazları güvenilmez ağlarda çalıştığı için kolayca kaybolabilir veya aynı veri birden fazla kez işlenebilir. Çözüm, ağı güvenilir kabul etmek yerine cihazı verinin geçici sahibi yapmaktır. Ölçümleri yerelde saklayın, bağlantı geldiğinde gönderin, her ölçüme sabit bir ID verin ve data ingestion katmanını idempotent tasarlayın. Firmware güncellemelerini ise tek seferde tüm filoya göndermek yerine kontrollü bir OTA rollout ile yönetin.

Saha verisi neden bozulur?

Bir IoT sisteminde cihazın internete bağlı olması garanti değildir. Sensör bir ölçüm aldığı anda bağlantı kopabilir, cihaz ölçümü gönderemeden offline olabilir, ve bağlantı geri geldiğinde daha önce gönderilmiş veriler yeniden gönderilebilir.

Bu durum iki farklı probleme yol açar: ilkinde veri tamamen kaybolur, ikincisinde aynı veri birden fazla kez sisteme ulaşır.

Örneğin bir sensör saat 14:00’de bir ölçüm aldı ve sunucuya göndermeye çalıştı. Tam o sırada bağlantı koptu, cihaz bağlantının başarısız olduğunu gördü ve veriyi tekrar göndermek üzere sakladı. Bağlantı geri geldiğinde aynı ölçüm tekrar gönderilir; sunucu bu ölçümün daha önce gelip gelmediğini anlayamıyorsa aynı veri iki kez kaydedilebilir.

Bu küçük bir teknik detay gibi görünür, ancak binlerce cihazdan gelen telemetrinin üzerine production kararları veriliyorsa sonuç oldukça ciddi olabilir.

Bu yüzden IoT tarafında temel soru şu değildir:

“Cihaz internete bağlı mı?”

Asıl soru şudur:

“Bağlantı yokken sistem ne yapıyor?”

Cihazı verinin sahibi yapın

IoT cihazları sahada çalışır, ağ ise her zaman güvenilir değildir. Bu nedenle önemli verilerin alınmasını doğrudan ağ bağlantısına bağlamamak gerekir.

Store-and-forward kullanın

Cihaz bir ölçüm aldığında bunu önce yerel depolamaya yazabilir, ardından bağlantı varsa gönderebilir. Bağlantı yoksa veri cihazda bekler, bağlantı tekrar geldiğinde cihaz daha önce gönderemediği ölçümleri sırayla iletir.

Böylece ağ kesintisi veri kaybına değil, sadece gecikmeye dönüşür. Bu yapı özellikle uzun süre offline kalabilen cihazlarda önemlidir: cihazın birkaç dakika veya birkaç saat bağlantısının kesilmesi, ölçümlerin tamamen kaybolması anlamına gelmemelidir.

IoT için uygun bir protocol kullanın

Cihaz ile sunucu tarafı arasındaki iletişimde kullanılan protocol de önemlidir. MQTT, düşük bant genişliği, sınırlı cihaz kaynakları ve bağlantının zaman zaman kesilebildiği ortamlar düşünülerek tasarlanmış bir messaging protocol’dür, bu nedenle IoT projelerinde sık kullanılan seçeneklerden biridir.

Ancak protocol seçimi tek başına problemi çözmez. MQTT kullanıyor olmanız, verinin otomatik olarak güvenli şekilde saklandığı veya tekrar gönderildiğinde duplicate kayıt oluşmayacağı anlamına gelmez. Asıl önemli olan cihaz ve sunucu tarafındaki veri akışının nasıl tasarlandığıdır.

Aynı ölçüm iki kez geldiğinde ne olacak?

Bir IoT sistemi için en önemli tasarım kararlarından biri budur. Cihaz bağlantı geri geldiğinde daha önce gönderdiği ölçümleri tekrar gönderebilir; bu normaldir, ve sunucu tarafının bunu hata olarak görmesi yerine aynı ölçümün tekrar gönderilebileceğini kabul etmesi gerekir.

Bunun temel yolu idempotent ingestion tasarlamaktır: her ölçüme benzersiz ve değişmeyen bir ID verirsiniz.

Örneğin:

device_id: sensor-42
measurement_id: 8f6c2d91
timestamp: 2026-06-18T14:00:00Z
temperature: 27.4

Aynı measurement daha sonra tekrar gönderilirse backend bunu yeni bir measurement olarak oluşturmak yerine aynı kaydın tekrar geldiğini anlayabilir.

Böylece cihazın retry yapması güvenli hale gelir.

Bu yaklaşımın önemli tarafı şudur:

Retry yapmak veri üretmemeli.

Retry yalnızca daha önce gönderilemeyen verinin tekrar gönderilmesi anlamına gelmelidir.

”Tam bir kez” veri nasıl sağlanır?

IoT sistemlerinde sık kullanılan bir hedef, verinin exactly once işlenmesidir.

Pratikte bunu yalnızca network veya messaging protocol’e güvenerek garanti etmek genellikle yeterli değildir.

Daha güvenilir yaklaşım, cihaz tarafında değişmeyen bir measurement ID üretmek ve backend’in aynı ID ile gelen kayıtları duplicate olarak tanıyabilmesini sağlamaktır.

Yani sistem şu ihtimali normal kabul eder:

Measurement alındı
↓
Gönderildi
↓
Bağlantı koptu
↓
Cihaz tekrar gönderdi
↓
Backend aynı ID'yi gördü
↓
Duplicate kayıt oluşturulmadı

Bu sayede network davranışı ne kadar düzensiz olursa olsun veri katmanı daha öngörülebilir hale gelir.

Fiziksel olarak ulaşamadığınız cihazları nasıl güncellersiniz?

Sahadaki cihazların hepsine tek tek gidip firmware güncellemek bazı sistemlerde mümkün değildir; yüzlerce veya binlerce cihazınız varsa bu yöntem kısa sürede operasyonel bir probleme dönüşür.

Burada OTA update devreye girer: cihaz yeni firmware’i uzaktan alır ve kurar. Fakat burada da önemli bir risk vardır. Eğer tek bir firmware’i aynı anda tüm filoya gönderirseniz, firmware içinde ciddi bir problem olması durumunda aynı problemi yüzlerce veya binlerce cihaza bir anda dağıtabilirsiniz.

Bu nedenle OTA update’i sıradan bir dosya transferi olarak değil, bir deployment olarak düşünmek gerekir.

OTA update nasıl güvenli yapılır?

İyi bir rollout genellikle küçük bir grupla başlar.

Örneğin:

Firmware v2.4
      ↓
10 cihaz
      ↓
Health check
      ↓
Sorun yok
      ↓
100 cihaz
      ↓
Health check
      ↓
Sorun yok
      ↓
Tüm filo

İlk grup sağlıklı çalışıyorsa deployment genişletilir, sorun tespit edilirse rollout durdurulabilir. Daha da önemlisi, cihazların eski firmware’e geri dönebileceği bir rollback mekanizması bulunmalıdır, böylece hatalı bir firmware tüm filoyu etkileyen bir probleme dönüşmeden önce yakalanabilir.

Bu yaklaşım yalnızca IoT için değil, genel olarak production deployment mantığıyla aynı prensibe dayanır:

Küçük bir grupta dene, sonucu gözlemle, sonra yay.

Cihazları sadece sunucu tarafından izlemeyin

IoT sistemlerinde önemli bir problem de sessizliktir. Bir cihaz hiçbir veri göndermiyorsa bu iki farklı anlama gelebilir: cihaz gerçekten sorunsuz çalışıyor olabilir ve sadece ölçüm üretmiyor olabilir, ya da cihaz tamamen offline olmuş olabilir.

Sunucu tarafında yalnızca gelen verilere bakarsanız bu iki durumu birbirinden ayırmak zorlaşabilir. Bu yüzden cihazların kendisini de gözlemlemek gerekir.

Örneğin şu bilgiler izlenebilir:

• Son heartbeat ne zaman geldi?
• Son ölçüm ne zaman alındı?
• Cihaz ne kadar süredir offline?
• Local buffer ne kadar büyüdü?
• Battery seviyesi nasıl?
• Firmware version nedir?
• Son OTA update başarılı oldu mu?

Bu bilgiler sayesinde sadece “veri azaldı” demek yerine daha anlamlı bir sonuca ulaşabilirsiniz:

“Sensor-42 iki saattir heartbeat göndermiyor ve local buffer büyüyor.”

İşte observability burada anlam kazanır: sadece veriyi değil, veriyi üreten cihazı da gözlemleyebilirsiniz.

Dashboard’a güvenmek yeterli değildir

Bir IoT sisteminin dashboard’ı çok iyi görünebilir. Grafikler çalışabilir, son ölçümler ekranda görünebilir. Ancak arka planda bazı cihazlar saatlerdir offline olabilir.

Bu nedenle dashboard yalnızca son durumu göstermekle kalmamalıdır. Sistemin sağlığını da gösterebilmelidir.

Örneğin bir yönetici için şu bilgiler daha değerlidir:

1.240 cihaz aktif
37 cihaz offline
12 cihazda buffer doluyor
8 cihaz eski firmware kullanıyor
3 cihaz OTA update sonrası hata verdi

Böyle bir dashboard yalnızca “ne oldu” sorusunu değil, “nerede problem var” sorusunu da cevaplar.

Güvenilir IoT mimarisinin temel akışı

Bütün bu yaklaşımı tek bir akışta düşünebiliriz:

Sensor
  ↓
Measurement
  ↓
Local storage
  ↓
Network
  ↓
Backend
  ↓
Idempotent ingestion
  ↓
Database
  ↓
Telemetry / Dashboard

Cihazın ağ bağlantısı kesilirse akış durmaz. Ölçüm yerel depolamada bekler, bağlantı geri geldiğinde yeniden gönderilir. Aynı ölçüm ikinci kez gelirse ID üzerinden duplicate olarak tanınır.

Böylece sistem ağın ideal çalışacağı varsayımına bağlı kalmaz.

Sonuç

Gerçek dünyadaki IoT sistemlerinin önemli bir kısmı kontrollü laboratuvar ortamlarında değil, bağlantının kesildiği, cihazların fiziksel olarak ulaşılması zor olduğu ve donanımın farklı koşullarda çalıştığı sahalarda yaşar. Bu nedenle güvenilir bir IoT architecture, ağın her zaman çalışacağını varsaymamalıdır.

Cihaz ölçümü yerel olarak saklamalı, bağlantı geri geldiğinde veriyi göndermelidir. Her ölçümün kendine ait bir ID’si olmalı, sunucu tarafı duplicate ölçümleri güvenli şekilde yönetmelidir. OTA update’ler kontrollü rollout ile dağıtılmalı, sorun olduğunda rollback yapılabilmelidir. Ve bütün bunlar observability ile izlenebilmelidir.

Özetle:

Ağ güvenilir değilse cihaz veriyi korur.

Veri tekrar gelebiliyorsa ingestion idempotent olur.

Firmware uzaktan güncelleniyorsa rollout kontrollü yapılır.

Cihaz sessiz kalabiliyorsa sistem bu sessizliği gözlemleyebilir.

Güvenilir IoT sistemi, sadece sensörden veri alan sistem değildir.

Sahanın gerçek koşullarında veri kaybetmeden, duplicate üretmeden ve gerektiğinde kendini güncelleyerek çalışabilen sistemdir.

Öne çıkan noktalar

• Saha cihazlarında ağ bağlantısının her zaman çalışacağını varsaymayın.
• Ölçümleri yerel depolamada tutarak store-and-forward yaklaşımı kullanın.
• Her ölçüm için değişmeyen bir ID üretin.
• Sunucu tarafında idempotent ingestion kullanarak duplicate kayıtları engelleyin.
• OTA update’leri tek seferde tüm filoya göndermek yerine aşamalı rollout ile yönetin.
• Firmware sorunlarında otomatik veya güvenli rollback mekanizması kullanın.
• Dashboard’ın yanında device health ve telemetry metrics’i de izleyin.
• Cihazların sessizliğini bir hata sinyaline dönüştürebilecek observability kurun. Gömülü sistemleri nasıl mühendislik ettiğimize bakın.