AWS Üzerinde Serverless Mimari Diyagramı: API Gateway, Lambda, DynamoDB ve Olaylar

Serverless bir sistemde sunucular ortadan kalkar, mimari diyagramın alışılmış şekli de onlarla birlikte gider. Bunun yerine önemli olan, her fonksiyonun nasıl tetiklendiği, başarısız olduğunda ne olduğu ve sistemin bir parçasını diğerine hangi olayların bağladığıdır. Yirmi Lambda kutusu çizip tek bir tetikleyici göstermeyen bir diyagram eksiksiz görünür ama hiçbir şeyi açıklamaz.

Bu rehber, AWS üzerinde yeni bir ekip arkadaşının takip edebileceği bir serverless mimari diyagramının nasıl çizileceğini gösteriyor: uçtan uca bir örnek, çağırma türleri ve hata yolları için bir gösterim ve bu diyagramları yanıltıcı hale getiren hatalar.

Her fonksiyonun nasıl çağrıldığıyla başlayın

Diyagramdaki her Lambda fonksiyonunu bir şey başlatır ve AWS, işler ters gittiğinde farklı davranan üç çağırma modeli sunar. Bir serverless diyagramının gösterebileceği en faydalı bilgi budur.

Çağırma modeli	Tipik kaynaklar	Hata durumunda kim yeniden dener	Hatalar nereye düşer
Senkron	API Gateway, bir fonksiyon URL'si, bir SDK çağrısı	Çağıran taraf karar verir	Çağıran tarafa dönen bir hata yanıtı
Asenkron	EventBridge, S3 bildirimleri, SNS	Lambda varsayılan olarak iki kez yeniden dener	Yapılandırdıysanız bir on-failure destination ya da dead-letter queue
Event source mapping (Lambda yoklama yapar)	SQS, DynamoDB Streams, Kinesis	Lambda batch'i yeniden denemeye devam eder	SQS: kuyruğun dead-letter queue'su. Stream'ler: bir on-failure destination; yoksa kayıtların süresi dolar

Her tetikleyici kenarını kaynağı ve modeliyle etiketleyin: sync, async ya da poll, batch 10. Bir arıza "mesajlar birikiyor" uyarısıyla başladığında herkesin ilk aradığı çizgi budur.

Örnek: serverless bir sipariş API'si

Tamamen yönetilen servisler üzerine kurulmuş küçük bir sipariş servisi:

1. İstemciler bir API Gateway HTTP API'sini çağırır. Bir JWT yetkilendiricisi, Amazon Cognito kullanıcı havuzunun verdiği token'ları doğrular.
2. API Gateway, createOrder fonksiyonunu senkron olarak çağırır. Fonksiyon isteği doğrular ve siparişi orders DynamoDB tablosuna yazar.
3. Tablo üzerindeki DynamoDB stream, publishOrderEvents fonksiyonunu tetikler; bu fonksiyon OrderPlaced olayını özel bir EventBridge bus'ına gönderir. Olay stream'den geldiği için yalnızca başarılı yazma işlemlerinde yayımlanır.
4. Bir EventBridge kuralı OrderPlaced ile eşleşir ve olayı receipts SQS kuyruğuna gönderir.
5. Lambda kuyruğu yoklar ve sendReceipt fonksiyonunu en fazla on mesajlık batch'lerle çağırır; fonksiyon müşteriye Amazon SES üzerinden e-posta gönderir.
6. Beş kez başarısız olan bir mesaj receipts-dlq kuyruğuna taşınır; orada bir alarm ekibi uyarır.

İstek yolu 2. adımda biter: sipariş kaydedilir kaydedilmez istemci yanıtını alır. Sonrasındaki her şey asenkrondur ve diyagram bu tetikleyicileri kesikli kenarlarla çizer.

Serverless diyagramlar için kurallar

Tetikleyicileri etiketli kenarlar olarak çizin

Bir fonksiyona giren kenar, onu neyin başlattığını söyler: POST /orders, DynamoDB stream, rule: OrderPlaced, SQS, batch 10. Gelen kenarı olmayan bir fonksiyon ya ölü koddur ya da diyagramınızda eksik bir çizgidir.

İstek yolunu asenkron işlerden ayırın

Senkron çağrılar için düz, sonradan gerçekleşen her şey için kesikli kenarlar kullanın. Okuyucu, kullanıcıya gecikme ekleyen yolu tek tek etiket okumadan izleyebilmelidir.

Hata yolunu bilinçli olarak çizin

Her asenkron kenar için hataların nereye gideceğine karar verin ve bunu çizin: bir dead-letter queue, bir on-failure destination ya da "kayıtların süresi 24 saat sonra dolar" yazan bir not. DynamoDB Streams kayıtları 24 saat saklar; bu yüzden sürekli hata veren bir tüketici, süresi dolan olayları kaybeder. S3'e giden bir on-failure destination başarısız kayıtların bir kopyasını tutar; SQS ya da SNS hedefine ise yalnızca metadata gider, dolayısıyla kayıtları bu 24 saat içinde stream'den geri okuyacak bir şey olmalıdır.

Her düğüme bir fonksiyon

Otuz fonksiyon için tek bir "Lambda" düğümü tetikleyicileri gizler; oysa mimari tam da tetikleyicilerdir. Fonksiyon sayısı çok fazlaysa kutuları birleştirmek yerine diyagramı servislere göre bölün.

Deploy birimine göre çerçeveleyin

Birlikte deploy edilen kaynakları, örneğin tek bir SAM, CDK ya da Terraform stack'ini, bir çerçevede toplayın. Böylece sahiplik ve neyin birlikte değiştiği görünür.

İzinleri ve limitleri not olarak tutun

Her fonksiyonun bir IAM yürütme rolü vardır; bazılarında ayrıca reserved concurrency ya da uzun zaman aşımları bulunur. Her fonksiyon için ayrı bir rol çizmeyin. Bir incelemede önemli olan şeyler için not ekleyin: "orders tablosuna yalnızca createOrder yazabilir", "SES limitlerini korumak için sendReceipt SQS tetikleyicisinde maksimum eşzamanlılık 5".

Sık yapılan hatalar

• API Gateway'i yük dengeleyici olarak çizmek. API Gateway kimlik doğrulaması da yapar, istek hızını sınırlar ve istekleri dönüştürür; yetkilendirici de diyagramda yer almalıdır.
• Eksik dead-letter queue'lar ya da kimsenin izlemediği dead-letter queue'lar. Alarmı da çizin.
• Kuralsız event bus'lar. Bir EventBridge bus'ı olayları kurallara göre dağıtır; kenarı yalnızca bus ile değil, kuralla etiketleyin.
• Senkron ile asenkronu ayırmamak. Bu, yavaş bir API ile yavaş bir e-posta arasındaki farktır.
• Altyapı gürültüsü. Log grupları, layer'lar ve her bir IAM politikası genel bakış diyagramına değil, şablona aittir.

Archboard'da oluşturun

Archboard'un Bulut paketi düğümleri sağlayıcıdan bağımsızdır ve portları vardır; bu yüzden her düğümü AWS servis adıyla etiketlersiniz:

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. İstemciler ve Amazon SES için Temel paketten Kutu düğümleri, Bulut paketinden bir API ağ geçidi ve Güvenlik paketinden Amazon Cognito etiketli bir Kimlik sağlayıcı ekleyin.
3. Her Lambda fonksiyonu için Bulut paketinden bir Fonksiyon ekleyin ve adını şablonunuzdakiyle birebir aynı koyun.
4. Bulut paketinden DynamoDB: orders etiketli bir Yönetilen veritabanı, Veri paketinden EventBridge bus etiketli bir Konu, kuyruk ve onun dead-letter queue'su için Bulut paketinden Kuyruk düğümleri ve alarm için DevOps paketinden bir Uyarı ekleyin.
5. Portları bağlayın. İstek yolunu düz bırakın, asenkron kenarları kesikli yapın ve her tetikleyiciyi kaynağı ve çağırma modeliyle etiketleyin.
6. Stack'i Temel paketten bir Çerçeve içine alın, izinler ve limitler için notlar ekleyin, ardından canlı bağlantıyı ekiple paylaşın.

Örnek 13 diyagram düğümü kullanır; bu da Free plana sığar. Serverless ya da container tabanlı bir iş yükünü çevreleyen ağ için AWS VPC diyagramı rehberine, daha fazla bulut kalıbı için bulut kullanım alanı sayfasına bakın.

SSS

Her Lambda fonksiyonunu çizmeli miyim? Servis diyagramında evet, çünkü her birinin kendi tetikleyicisi ve hata davranışı vardır. Sistem genel bakışında servisi tek bir düğüm olarak gösterin ve servisin kendi diyagramına bağlantı verin.

Resmî AWS ikonlarını kullanabilir miyim? Archboard'da AWS için özel bir paket yok: diyagramı Bulut, Ağ ve Güvenlik paketlerindeki portlu, tipli düğümlerle kurun ve her birini Amazon SES ya da DynamoDB: orders gibi servis adıyla etiketleyin. Logo da istiyorsanız, Ara ve ekle ile AWS Lambda gibi AWS servislerinin marka ikonlarını bulup ikon düğümü olarak yerleştirebilirsiniz.

Step Functions'ı nasıl gösteririm? Mimari diyagramda durum makinesinin adıyla etiketlenmiş tek bir düğüm olarak; iş akışının kendisini ise ayrı bir akış şeması ya da BPMN diyagramı olarak.

Cold start'lar ve eşzamanlılık nereye yazılır? Önemli oldukları fonksiyonların yanındaki notlara; örneğin gecikmeye duyarlı bir endpoint'teki provisioned concurrency.

IAM rollerini göstermem gerekir mi? Düğüm olarak değil. Tasarımı şekillendiren izinleri not edin, politikaların tamamını ise altyapı kodunuzda tutun.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.