Zenn
Open4

[メモ]FRP/Serverパフォ/分散検索/Doc

Java
network
Elasticsearch
as_pmlas_pml

リアクティブ プログラミング

関数型リアクティブ プログラミング (FRP)

as_pmlas_pml

サーバーサイドパフォーマンスチューニング

ISUCON

高パフォーマンスの鍵

  1. 帯域まで考慮すると1台構成がスコアが高そう
  2. キャッシュ
  3. SQL/DBスキーマを書き換える
  4. インメモリキャッシュで全て捌く
    ・公式チューニング例

チューニング

パフォーマンス測定

  1. 負荷試験ツールを利用する（APIに負荷をかける）
    　→vegetaなどがある
  2. 100RPS×5s = 500Reqsで比較する

1.キャッシュ

手段

  • ローカルキャッシュ（インメモリ）
  • RedisやMemcachedを使用し複数台でキャッシュを共有する
  • 上記2点を併用し、多段キャッシュを構築する

効果とトレードオフ

  • DBアクセスや負荷の高い計算処理をカットできる
  • キャッシュに残っている古いデータをクライアントに返すリスクがある
  1. 古いデータを参照し続けるリスクを軽減するためTTLを設定する
  2. 適切なTTLの値はデータの特性によって異なる
  3. データの不整合にシビアな場合には1秒程度のキャッシュでも効果がある
  4. アクセス頻度が低い場合やキャッシュヒット率が期待できない場合には通信回数が増えるだけなのでパフォーマンスが低下する

2.レスポンス圧縮

手段

  • レスポンスを圧縮する（gzip, brotli, ...）

効果とトレードオフ

  • レスポンス圧縮により帯域を節約
  • クライアント側で対応が必要（解凍しないといけない）
  • アーキテクチャの変更対応は必要ない

3.CDN(Contents Delivery Network)の使用

手段

  • CloudFront (AWS), Cloud CDN (GCP), Akamai, Fastly, ...
  • 上記をオリジン（リクエストを受けるサーバー）の前段に配置

効果とトレードオフ

  • CDNによりサーバーへのアクセスを軽減できる
  • CDNによりエッジロケーションへの応答速度をあげることができる
  • CDNを使用することで古いデータ参照が起こり得る

導入

  1. オリジンとしてALBを前段に配置する
  2. Cache-Controlヘッダをレスポンスに追加する
  3. max-age, s-maxageでTTLを設定する

4.常時接続の選択肢を採らない

手段

  • 常時接続系APIではなくポーリングを採用する

効果とトレードオフ

  • ステートレスな設計を維持しやすいため、スケール性に優しい
  • リアルタイム性を犠牲にするので、サービスの特性によっては許容できない
    　→この場合にはニアリアルタイムで要件を満たせないかを考えたい（クライアントに見せ方次第で工夫できないか）
  • 接続保持（＝状態を持つ）→スケールに考慮が必要

5.非同期メッセージング

手段

  • 非同期で実行できる処理はメッセージキューに入れて後で処理
  • Cloud Pub/Sub, Kinesis Data Streams, SQS,...

効果とトレードオフ

  • クライアントにレスポンスを返すことを優先できる（レスポンスタイム向上）
  • メッセージキューを使用する場合、冪等性のある処理にする必要性あり
  • ファンアウトと疎結合化

メッセージキュー使用タイミング

  • 時間のかかる処理かつ同期的に実行する必要がない
  • リトライを行いたい
  • イベント駆動で動作させたい処理がある
  • 後続処理が多く、並列に動作させたい/ファンアウト先を増やしたい

キャッシュに対して考えるべきこと

完全にサービスの機能や特性に応じて考える必要がある

  • 異常系をキャッシュ（ネガティブキャッシュ）するか
  • TTLをどうするか
  • ClondFrontの場合4xx系、5xx系はデフォで10秒キャッシュされる
  • TTLが大きい→異常が発生した際にオリジンに負荷がかからない
  • TTLが大きい→復旧後もユーザーに異常系が返り続ける
as_pmlas_pml

分散検索/分析エンジンElasticsearch

アトミックな更新

  1. インデックスエイリアスから
    ・後ほど削除するインデックス
    ・ドキュメントのインデックス
    の２つを参照する
    ←エイリアスを用いると複数インデックスを参照できる
  2. インデックステンプレートはドキュメントのインデックスから生成される
    ←インデックステンプレートにはマッピングが定義されており毎度手動で定義せずとも自動的に定義してくれる
  3. ドキュメントにはバッチ処理がかかる

→新しいインデックスが完成した後に古いインデックスを消せばアトミックな更新ができる

KyeWord

マネージドサービス

  • 管理が簡単になる
  • AWS Elasticserch Serviceは設定が楽だが..(awsとelastic社が喧嘩しているので動向注意?!)

シャード・ノード数

  • インデックスデータサイズ/30GB = シャード数
  • ノード数は3つが最低ライン（スプリットブレイン対策）
    スプリットブレイン=同期の取れない複数のマスターが発生することでデータの整合性が失われる現象

kibana

as_pmlas_pml

開発ドキュメント

システム開発時

  1. 設計書
    ・要件定義書
    ・基本設計書
    ・開発設計書（プログラム定義書）
    ・テスト仕様書
  2. 計画書
    ・システム導入スケジュール
    ・システム移行計画
    ・工数管理
    ・アサイン計画（内部的開発計画）
  3. 提案書
    ・対ユーザー新規開発提案書
    ・提案依頼書（RFP）：システム要件、サービス内容、契約条件
  4. ユーザーマニュアル
  5. 報告書