ソフトウェアデザイン2024年10月号を読んで気になったものメモ
きよまるGoogleが発表した送信電子メールにおけるガイドライン
Software Design 編集部. Software Design (ソフトウェアデザイン) 2024年10月号 [雑誌] (p.44). 株式会社技術評論社. Kindle 版.
SPF、DKIM、DMARCはすべてDNSを利用して、送信されてきたメールが本当に表示されているドメイン、IPアドレスから送信されているのかを検証し、検証結果によってMTAやスパムフィルタ側へ処理を指示できます。
Software Design 編集部. Software Design (ソフトウェアデザイン) 2024年10月号 [雑誌] (p.52). 株式会社技術評論社. Kindle 版.
全員が高い意識を持たなければ保てないしくみは誤っています。マーフィーの法則に「失敗する余地があるなら、失敗する」という経験則がありますが、腐る余地があるものは必ず誰かが腐らせるのです。
Software Design 編集部. Software Design (ソフトウェアデザイン) 2024年10月号 [雑誌] (p.79). 株式会社技術評論社. Kindle 版.
① 設計ドキュメントにも保守コストがかかることを理解し、できる限り余計なものを作成しない
② 作成フローを一方通行にすることで、ソースコードと設計ドキュメントのダブルメンテナンスを避ける
③ 設計ドキュメントとソースコードの整合性を取るため、レビューや静的解析のチェックで同期を取る
Software Design 編集部. Software Design (ソフトウェアデザイン) 2024年10月号 [雑誌] (p.79). 株式会社技術評論社. Kindle 版.
きよまるADRとは、ソフトウェア開発やシステム開発において、アーキテクチャに関する重要な意思決定を記録するための文書です。なぜその決定が行われたのかを説明し、将来同じ問題に直面した際にその背景を理解・議論するためのものです。
きよまるオンラインによる本人確認と一口に言っても、eKYC手法の中にも方式がいくつか存在します。本章では、「ホ」「ヘ」「ト」「ワ」という代表的な4つの方式を紹介します。それぞれの特徴やしくみを確認していきましょう。
きよまるよりセキュアで利用が簡単なオンライン上の本人確認技術として、eKYCのワ方式ことJPKI（公的個人認証サービス）があります。名前のとおり暗号技術の1つであるPKI（公開鍵基盤）が使われた本サービスについて、詳しく見ていきましょう。
きよまる既存の課題（マイクロサービス化によるもの)
マイクロサービスの呼び出しに伴う通信を、そのままブラウザやスマートフォンアプリといったクライアントから直接行おうとすると、サーバとの通信回数が何倍にも増えてしまいます。もし1回のサーバとの通信で必要な情報が集められない場合は、複数回同じサーバに通信する必要が出てきてしまいます。とくにスマートフォンの場合は、通信回数が増えることで電池の消費も増えてしまうのでより大きな問題となります。
1つ目の課題は、クライアントと各マイクロサービスの間にZOZO Aggregation APIというBFFを配置して、通信量を抑えることで解決しました（図1）。クライアントへのレスポンスも、重複した内容を削りながら必要としている情報を整理してレスポンスできるようになっています。また今後さらに必要なマイクロサービスが増えたとしても、ZOZO Aggregation API内でレスポンスを1つにまとめられるので、クライアント側の通信に大きな影響を与えずに済みます。もちろん表示するコンテンツを増やした場合はレスポンスのサイズも増えますが、クライアントの通信回数を増やした場合よりも抑えられると考えています。
きよまる一般的に、キャッシュを保存するときは有効期限を設けて、期限が来たら自然に消えていくように設計することが多いと思います。この場合、キャッシュの有効期限が切れたタイミングで、瞬間的にマイクロサービスへリクエストが殺到することになります（図4）。せっかく負荷を減らしたにもかかわらず、マイクロサービスへの負荷が一気に増大してしまうということです。この現象は一般的にCache Stampede（キャッシュスタンピード）、Dog piling（ドッグパイル）などの名称で呼ばれています。
きよまるChatGPTのメモ
**キャッシュスタンピード（Cache Stampede）**は、キャッシュの有効期限が切れたときに、複数のクライアントが同時にバックエンドにリクエストを送信し、バックエンドサーバーに過負荷がかかる現象を指します。キャッシュが失効しているため、通常はキャッシュにヒットするリクエストが全てバックエンドに到達し、システムが急激に高負荷になる問題です。
キャッシュスタンピードの発生する状況
-
キャッシュ有効期限切れ
キャッシュ内のデータには通常、有効期限（TTL: Time To Live）が設定されています。この期限が切れた後、キャッシュは新しいデータを取得するためにバックエンドへリクエストを送信します。 -
同時アクセス
キャッシュが有効期限切れになるタイミングで、多数のクライアントが同時に同じキャッシュにアクセスしようとすると、全てのリクエストがバックエンドに流れ込み、バックエンドに負荷が集中します。
キャッシュスタンピードの問題点
バックエンドに負荷が集中
キャッシュスタンピードが発生すると、本来はキャッシュにヒットするはずのリクエストがバックエンドに向かい、負荷が増大します。特に、アクセスが多い場合やリソースの取得・計算が重い場合、バックエンドがオーバーロードする可能性があります。
パフォーマンス低下
大量のリクエストがバックエンドに集中すると、レスポンスが遅くなり、最悪の場合、システム全体が停止することもあります。
キャッシュスタンピードの対策
- ミューテックス（Mutex）ロックの利用
キャッシュが無効になった際に、最初にバックエンドにデータを取りに行くリクエストのみがキャッシュを再構築するようにする。他のリクエストはキャッシュの再構築が完了するまで待機する。
方法: memcachedやRedisのようなキャッシュストアを使って、キャッシュの更新処理に排他ロック（mutex）をかける。
例：RedisのSETNXを使った擬似ロック
if redis.setnx("lock:key", "1")
redis.expire("lock:key", 10) # ロックの期限設定
キャッシュの再構築処理
else
ロックが解除されるまで待つ
end
- ソフトTTL（Soft TTL）とハードTTLの併用
キャッシュにソフトTTLとハードTTLの2つの期限を設定します。
ソフトTTL: 有効期限切れ後も、キャッシュされた古いデータを短期間提供し続ける。
ハードTTL: これを超えるとキャッシュは無効になり、新しいデータを必ず取得する。
これにより、ソフトTTL期間中にキャッシュの再構築をバックグラウンドで行い、同時に複数のクライアントがキャッシュを再構築しないようにします。
- キャッシュの有効期限の分散
キャッシュの有効期限をクライアントごとにランダム化することで、全てのキャッシュが同時に有効期限切れにならないようにします。これにより、一斉にバックエンドへのリクエストが発生するのを防ぎます。
例：TTLにランダム要素を加える
ttl = 3600 + rand(300) # 1時間 + ランダムで最大5分延長
cache.set("key", value, ttl)
- バックグラウンドでのキャッシュ再構築
定期的にバックグラウンドジョブ（例えば、Cronジョブやキューシステム）を使って、キャッシュの再構築を行い、キャッシュの失効を予防します。
キャッシュスタンピードのまとめ
問題: キャッシュの有効期限が切れたときに、同時に大量のリクエストがバックエンドに向かい、システムに過負荷がかかる現象。
対策: ミューテックスロック、ソフトTTLの導入、キャッシュの有効期限の分散、バックグラウンド再構築などの方法で、スタンピードを防止できます。
キャッシュスタンピードは、特に高トラフィックのアプリケーションで発生しやすいので、これらの対策を考慮に入れることが重要です。
きよまる"Software Design (ソフトウェアデザイン) 2024年10月号 [雑誌]"（Software Design 編集部 著）からのこの引用を読んであなたのことを思い出しました。
"重要だが緊急ではないことは、結局進めないと緊急度も上がらない、もしくは、進めたいころにはもう遅いです。だから、自分で動かして現実にしていくしかないのだと思います。"
■現場をつなぐ
チームをつなく
共通言語を作る
ユーザーに見えるようにする
■経営とつなぐ
事業の方向性を自分の言葉で話す
正しく評価できるようにする
巻き込める環境を作る
メモ。
ここは自分の考えと近い。
共通言語を作るは良い取り組みなので導入する
きよまるDurable Objectsはトランザクションストレージというしくみを持っていてインスタンス内部からアクセスすることが可能なのですが、これが強整合性が保証されたKey-Valueストレージとなっているため排他処理を実現できます。 以前からもCloudflare Workers KVというCloudflare Workersから呼び出して使えるKey-Valueストレージがありましたが、こちらは結果整合なストレージであり最終的な一貫性はあるものの、エッジ間同期前に同じキーに対して書き込みがあった場合には書き込みタイミングが遅いほうで上書きされます注2。 強整合性が求められる場面ではDurable Objectsのトランザクションストレージを使うことが適しているのです。
Software Design 編集部. Software Design (ソフトウェアデザイン) 2024年10月号 [雑誌] (p.359). 株式会社技術評論社. Kindle 版.
きよまるExpress One Zoneには主に3つの特徴があります。 ・ 単一のAZにデータを保管 ・ ディレクトリバケット ・ セッションベースの認証
Software Design 編集部. Software Design (ソフトウェアデザイン) 2024年10月号 [雑誌] (p.376). 株式会社技術評論社. Kindle 版.