0218
LOGS
- 社内技術課題の一つを使って，インフラの勉強
Reverse Proxy
- Web サーバーの前段に立ち、様々な機能を提供するもの
- Web アプリケーションのアーキテクチャにおいて、ほぼデファクトスタンダードと言えるほど広く採用されている
- セキュリティの向上:
- DDoS 攻撃対策: 大量のトラフィックを Reverse Proxy で吸収し、Web サーバーへの負荷を軽減します。
- WAF (Web Application Firewall) 機能: 不正なリクエストを検出し、Web サーバーへの攻撃を防ぎます。
- SSL/TLS 終端: 暗号化処理を Reverse Proxy で行うことで、Web サーバーの負荷を軽減し、セキュリティを強化します。
- パフォーマンスの向上:
- キャッシュ機能: よくアクセスされるコンテンツをキャッシュし、Web サーバーへのリクエスト数を減らすことで、応答時間を短縮します。
- ロードバランシング: 複数の Web サーバーにリクエストを分散し、Web サーバーの負荷を均等化します。
- 圧縮: レスポンスを圧縮することで、ネットワーク帯域幅を節約し、高速な配信を実現します。
- 柔軟性の向上:
- Web サーバーの構成: Reverse Proxy は、Web サーバーの構成を隠蔽できます。これにより、Web サーバーの変更や移行が容易になります。
- A/B テスト: Reverse Proxy を用いて、異なるバージョンの Web アプリケーションを同時に提供し、A/B テストを実施できます。
- 使わないケース
- シンプルな構成: Web サーバーが 1 台のみで、特別な要件がない場合は、Reverse Proxy を導入する必要がない
- リバースプロキシによるロードバランシングの主な方式
- ラウンドロビン: リクエストを順番に各サーバーに割り当てます。
- ンドロビン: 各サーバーに重みを設定し、重みに応じてリクエストを割り当てます。
- 最小接続数: 接続数が最も少ないサーバーにリクエストを割り当てます。
- IP ハッシュ: クライアントの IP アドレスをハッシュ化し、特定のサーバーにリクエストを割り当てます。
- Read API と サービスから直でキャッシュサーバーにアクセスする場合
- 直の方はリアルタイム性を重要視する必要がある
- キャッシュの更新頻度やその戦略が大事だな
- 知らないワード達
- Write-through (ライトスルー)
- Write-back (ライトバック)
- Cache-aside (キャッシュアサイド)
- write-through が一番良さそうに思うが，オーバーヘッドはなぁ．あとはキャッシュデータの浸透率の話（良く批判が来るワード）もあるのでキャッシュアサイドが良いのか？
- 有効期限 (TTL) を設定することで、キャッシュの鮮度を保つことも重要
Fanout Service とは
- SNS やメッセージキューなどの仕組みを利用して、1 つのメッセージを複数の宛先（今回は、タイムラインを表示するユーザー）に効率的に配信するためのサービス
- 役割
- ツイートの受信: Write API からツイートを受け取る
- フォロワーリストの取得: User Graph Service から、ツイートしたユーザーのフォロワーリストを取得
- メッセージの配信: 取得したフォロワーリストに基づいて、各フォロワーのタイムラインにツイートを配信
- この際、メッセージキュー (例: Kafka) を利用することで、大量のメッセージを効率的に配信できる
CAP定理
