DAY1

負荷分散とは

• 可用性を高めるための手段
• 存在しなかったら
  • 一台のサーバーで全てのリクエストを捌かないといけない
  • 複数台用意したとして
    • リクエストの振り分け方は？
    • 1台が死んだ時の対処法は？

ロードバランシングの種類

• RoundRobin
  • 順番に均等に振り分ける
• LeastConnections
  • コネクション数を見て少ないサーバに転送
• DNSラウンドロビン
  • ドメイン索引時にIPアドレスを交互に返す
• L4ロードバランシング
  • メリット
    • LBのIPを固定できる
    • 効果養成、高スループット、低レイテンシ
• L7ロードバランシング
  • HTTP/HTTPSの機能を使った負荷分散
  • いろんなルーティングができる
  • 一旦L7を選定するということが多いかも
    • 普段使いしやすい&柔軟
  • ネットワークの要件が高い場合はL4

スティッキーセッション

セッションが続いている間は同じクライアントを同じサーバへ誘導する機能

均等に振り分け続けるとクライアントの情報を保持していないサーバにリクエストしてしまうことがあるため

DAY2

• AWSではEC2の中にあるロードバランシングの項目を見る
• ロードバランサータイプ
  • Application = L7
• internet-facing = public Subnetに配置している
• Private ALBになるケース（蛇足メモ）
  • コンテナ間通信、internal ALBなどの場合
  • サービスディスカバリなどを最近採用するケースが多い
• ALBはサブネットに配置するため、VPCができている前提
• DNSは必ず払い出される
• トラフィックの設定
  • ユーザーからのリクエストでヘッダーなどの情報が欠落しないように見直すところ
• リスナーとルール
  • ポート
    • 例：HTTPS:444なら444 のポートで来たリクエストに対してどのように振る舞うか
  • ターゲットグループ
    • 転送先
    • リダイレクトや固定レスポンス（エラーなど）を返すこともできる
    • if文（ルール条件の定義）で、IPやパスで条件分岐させることも可能
      • ALBの責務にするべきか、アプリケーションの責務にするべきかは設計次第
    • 登録済みターゲット
      • ECS on Fargateで指定する
      • ヘルスチェックが通っているとHealthy と表示される
      • リクエストエラーが発生している場合はヘルスチェックの値を確認
• ALBの性能限界を超えるような時は、暖機申請をする
  • 5分間で50%以上のトラフィック増加があると、ALBのスケールが間に合わなくなってくるかもしれない（参考）