メインコンテンツまでスキップ

Performance Testing and Regular Maintenance

API Gateway パフォーマンステスト​

パフォーマンステストのチェックポイント

  • 総コール数、総コール成功数、総コール失敗数、成功/失敗ステータス:

失敗の数は、実際のアプリケーションで発生した致命的なエラー（401や499など）ではない場合があるため、ステータスコード（成功/失敗ステータス）を確認する必要があります。

  • トップ5 APIコール - バー、テーブル

パフォーマンステスト中に主に呼び出されるAPIのステータスを確認できます。

  • トップ5 APIレスポンス遅延
    • APIを呼び出す際の遅延が遅いAPIを示します。
    • ゲートウェイレスポンス遅延: ゲートウェイによって引き起こされる遅延
    • バックエンドレスポンス遅延: バックエンドアプリケーションのレスポンス遅延
    • APIレスポンス遅延: ゲートウェイレスポンス遅延とバックエンドレスポンス遅延の結果
    • すべてのレスポンス遅延値はミリ秒（ms）で測定されるため、100msの遅延は0.1秒に過ぎず、特に遅いわけではありません。一般的に、1000ms（1秒）程度のレスポンスタイムは遅いと見なされます。
  • サイドカーとして実行されているIstioの仕様も確認する必要があります。

パフォーマンスの測定方法の説明​

  • RPSテスト: 秒あたりのリクエストの測定
  • バルクテスト: リクエストデータサイズとレスポンスデータサイズが設定された条件下での測定。
  • 遅延テスト: 遅延が強制される環境でのパフォーマンスの測定
  • エイジングテスト: 長時間の継続的なテストと、メモリリークやストレージ容量の増加の測定
SettingValueNote
CPU2 Core2 worker process
Memory2 Gib
Replicas1 unitゲートウェイが冗長かどうか
Requests per second1000 unitRPS
Request data size100 KBバルク（リクエスト）
Response data size100 KBバルク（レスポンス）
Forced response delay1 second遅延
テスト時間8時間エイジング

複雑な条件 (RPS+バルク+遅延+エイジング) テスト結果​

  • 合計所要時間: 8時間 エイジング
  • 合計リクエスト: 28,800,000 コール
  • 成功したリクエスト: 28,800,000 コール
  • 成功/失敗率: 成功 100.0% (失敗 0.0%)
  • 平均応答時間: 15ms

定期メンテナンスチェックリスト​

APIMコンポーネントの定期メンテナンス​

  • APIMコンポーネントポッドが正常に動作していることを確認する
$ kubectl get pods -n {APIM_NAMESPACE}
NAME                                        READY     STATUS     ...
deploy-apim-devlopers-portal-backend         1/1      Running
deploy-apim-devlopers-portal-frontend        1/1      Running
deploy-apim-bff                              1/1      Running
deploy-apim-analysis-manager                 1/1      Running
deploy-apim-gateway-manager                  1/1      Running
deploy-apim-tenant-manager                   1/1      Running
deploy-apim-tenant-manager-console           1/1      Running
deploy-apim-policy-manager                   1/1      Running
apim-mariadb-master-0                        1/1      Running
statefulset-pgauth-0                         1/1      Running
  • APIMコンポーネントデータベースストレージの容量を確認する
$ kubectl exec -it apim-mariadb-master-0 bash -n {APIM_NAMESPACE}
(mariadbコンテナ) $ df -h
...
/dev/nvme8n1    4.9G  451M  4.4G  10% /bitnami/mariadb
...

$ kubectl exec -it statefulset-pgauth-0  bash -n {APIM_NAMESPACE}
(postgresqlコンテナ) $ df -h
...
/dev/nvme10n1   4.9G  624M  4.3G  13% /pgdata
...
  • コンソールアクセス

アクセスURLを確認する（Ingress情報を使用して確認） - 以下のホスト名は例です。

$ kubectl get ingress -n {APIM_NAMESPACE}
NAME                                        HOSTS
deploy-apim-devlopers-portal-backend       apim.sk.com
deploy-apim-devlopers-portal-frontend      apim-tenant.sk.com
deploy-apim-bff                            apim-developers.sk.com

ウェブブラウザで上記の情報を使用して正しくアクセスできるか確認してください：

  • APIMコンソール

  • テナントマネージャーコンソール

  • 開発者ポータル

APIゲートウェイ定期メンテナンス​

  • APIMコンソール画面にアクセスし、ゲートウェイのステータスを通常通り確認します
    • APIMコンソール > ゲートウェイ管理 > ゲートウェイを選択
    • 六角形の形状が設定されたレプリカの数に応じて完全に埋まっているか確認します → 問題がある場合（例：ポッドが保留中）、六角形の形状は回転アニメーションを表示します。

  • ロギングデータを通じて正常な呼び出しを確認します（APIロギング項目を参照）
    • Kibana > ダッシュボード > APIMダッシュボード
    • 呼び出しの数と成功/失敗のステータスを確認します

  • 監視データを通じてAPIゲートウェイリソースを確認します（APIゲートウェイ監視項目を参照）：Grafana > ダッシュボード > ブラウズ > APIMダッシュボード：
    • API呼び出しに関連するダッシュボード
    • 秒あたりの呼び出し数を確認します
    • APIのレイテンシを確認します

  • Grafana > ダッシュボードブラウズ > コンテナダッシュボード > Kubernetes: デプロイメント：
    • APIゲートウェイリソースを確認します
    • CPU、メモリを確認します