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

Performance Testing and Regular Maintenance

API Gateway Performance Testing​

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

  • 総コール数、成功したコール数、失敗したコール数、成功/失敗ステータス：

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

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

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

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

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

  • RPSテスト：秒あたりのリクエストの測定
  • バルクテスト：リクエストデータサイズとレスポンスデータサイズが設定された条件下での測定。
  • 遅延テスト：遅延が強制される環境でのパフォーマンスの測定
  • エイジングテスト：長時間の継続的なテストと、メモリリークやストレージ容量の増加の測定
SettingValueNote
CPU2コア2ワーカープロセス
メモリ2 GiB
レプリカ1ユニットゲートウェイが冗長かどうか
秒あたりのリクエスト1000ユニットRPS
リクエストデータサイズ100 KBバルク（リクエスト）
レスポンスデータサイズ100 KBバルク（レスポンス）
強制レスポンス遅延1秒遅延
テスト時間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 container) $ df -h
...
/dev/nvme8n1    4.9G  451M  4.4G  10% /bitnami/mariadb
...

$ kubectl exec -it statefulset-pgauth-0  bash -n {APIM_NAMESPACE}
(postgresql container) $ 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

上記の情報を使用して、Webブラウザで正しくアクセスできるか確認します：

  • APIMコンソール

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

  • 開発者ポータル

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

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

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

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

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