Akamai CDNの動作確認をするTest Centerなどの自動化ツールの利用方法を考える

# Akamai CDN での動作確認の方法
Akamai CDNでは、Production(本番環境)のProperty(配信設定)に影響を与えることなく、設定内容の動作検証・機能テストを実施する事ができる Staging(検証環境)を提供しています。

- [Staging環境での動作検証手順について](https://community.akamai.com/customers/s/article/Stagingrxdxn?language=en_US)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/49877/a3580765-9c56-c9a0-caaa-ef40d5f3950a.png)

Staging環境で動作検証等テストを行う場合は、Digital Property（クライアントが使用する接続先のFQDN）をStaging用のAkamaiのIPに向けます。この方法を”Spoofing（スプーフィング）”と言います。
実際にSpoofing（スプーフィング）の動作検証を実施します。

**Spoofing（スプーフィング）手順**

Digital Property:  www.example.com
Edge Hostname:  www.example.com.edgesuite.net
Staging Edge Hostname: www.example.com.edgesuite-staging.net

StagingのIPアドレスを確認する

```
~ dig www.example.com.edgesuite-staging.net +short
axxx.dscd.akamai-staging.net.
xxx.xxx.xxx.xxx
xxx.xxx.xxx.xxx
```

IPアドレスをhostsに設定し、www.example.comをStagingに向き先を変えます。(Spoofing)

```
~ vim /etc/hosts
xxx.xxx.xxx.xxx www.example.com
```

## Staging環境での動作確認

Staging環境への疎通確認は一般的には以下のような方法を用いて確認するケースが多いです。

- ブラウザを利用したサイトへのQAテスト
- curlを利用したコンテンツへの疎通確認
- Apache JMeterなどを利用したシナリオテスト
- Seleniumなどを利用したE2Eテスト
- スマホアプリを用いたQAテスト
    - DNSサーバーをdnsmasqやBINDなどで構築しSpoofingを実現
    - Charlesを用いて端末をProxyとしてSpoofingを実現

上記いずれの手順も単一のサイト更新で利用することが多く、多くのサイトを抱えていたり、設定を頻繁に変更する際には確認の工数が多くかかります。
また、Propertyの変更作業をTerraformなどでコード化していても、Stagingでの確認にて時間がかかるケースもあります。
そのため、CI/CDも見据えた確認が必要になる際には自動化を考慮した手法が必要となります。

## Akamai Test Center とは

Akamai Test Centerでは、curlによる接続テストやテストケースを利用した機能テスト、ProductionとStagingの機能差分テストを行うことができます。
テストではPragmaヘッダーの付与も行うことができます。
また、APIやCLIも提供しており接続テストをより簡単に自動化していくことができます。
Stagingをテストするためのスプーフィング設定を行う必要もなく、環境を選択するのみでテストできます。

- [Welcome to Test Center](https://techdocs.akamai.com/test-ctr/docs/welcome-test-center)

**Functional testing (機能テスト)**

機能テストは、期待される動作を確認するための条件を設定し、構成変更の正しさをテストできます。テスト要求に対して、期待される HTTP 応答と実際の HTTP 応答、あるいはプロパティ設定値を比較します。変更を単独でテストすることもStaging, Productionの環境を指定してテストをすることができます。

**Comparative testing (比較テスト)**

比較テストでは、ホスト名がステージング環境と本番環境でどのように振る舞うか、あるいは2つの本番環境でどのように振る舞うかを比較するために使うことができます。


### 機能テストを試す

機能テストを試すため、テストケースを作成します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/49877/8fdf6629-dfd0-9dc1-96ac-965f68aa3848.png)

テストケースでは、特定のURLに対して、Pragmaヘッダーなどを付与することができ、その状態が正しいものであるかを確認することができます。
一般的なツールの場合には応答が行える要素が判断するポイントとなりますが、Test Center特有の機能としてProperty Manager Behaviorの状態が確認できます。

- [Example: create a condition](https://techdocs.akamai.com/test-ctr/reference/example-create-condition)

condition(条件)では以下の値を利用することができます。
例えばProperty ManagerのCaching時間が正しいかなどの確認も行えます。

- RESPONSE_CODE
- RESPONSE_HEADER
- CACHE_KEY_QUERY_PARAMETERS
- CACHING
- CONTENT_PROVIDER_CODE
- IGNORE_CASE_IN_CACHE_KEY
- LAST_MILE_ACCELERATION_(GZIP_COMPRESSION)
- LOG_REQUEST_DETAILS
- ORIGIN_SERVER
- PREFETCH_OBJECTS
- REDIRECT
- SURE_ROUTE
- TIERED_DISTRIBUTION
- VARIABLE
- ALERTED_RULES
- DENIED_RULE
- POLICY_NAME
- API_ID

:::note warn
condition(条件)はあくまでも、値があるかないか、有効か無効かの簡単な確認にのみ利用することができ、複雑な条件の指定、Propertyの構成に関しての詳細な確認を行うことはできませんのでご注意ください。
:::

設定したテストケースを実行することで、テスト結果が正常なのか誤りなのかを確認することができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/49877/dfa0ad65-54bf-614e-c876-9dc0f4c071fa.png)

テスト結果はPDFとしてダウンロードすることもでき、エビデンスとして残すことができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/49877/8749b769-d9a5-9a4d-899e-67fbdf1aa119.png)

### Test Center CLI を試す

上記の通りACCからテストケースを実行することもできますが、お勧めの利用方法としては、ACCからFunctional testingでテストケースを作成し、実行はCLIにて行う方法です。

- [CLI Test Center](https://github.com/akamai/cli-test-center)

テストケースはJSONにて記載することもできますが記載方法が難しく、先ほどACCから作成したテストケースのIDを控えておくことでCLIからの実行を行うことができます。
このCLIを利用することでCI/CDへ組み込みやすくなります。

作成したテストケースのIDををCLIで指定して、テストを実行してみます。

```
akamai test-center test run --test-suite-id xxxxxx --env STAGING
Running test suite...... [OK]
Test run with id xxxxx started.

Running tests...... [OK]

TEST SUMMARY

Status: Completed
Target Environment: Akamai staging

Test suite: test | 2 test cases - 2 passed

        1 GET https://example.com/html/index.html | CURL:7.81.0 + IPv4
     Test case execution id: xxxxxxxxx
     Customized headers: (Added): Pragma: akamai-x-cache-on,akamai-x-cache-remote-on,akamai-x-check-cacheable,akamai-x-get-true-cache-key,akamai-x-get-cache-key,akamai-x-serial-no,akamai-x-get-request-id
     Expected: Response code is one of "200"
     Actual: Response code: "200"
        Status: Passed

        2 GET https://example.com/html/index-2.html | CURL:7.81.0 + IPv4
     Test case execution id: xxxxxxx
     Customized headers: (Added): Pragma: akamai-x-cache-on,akamai-x-cache-remote-on,akamai-x-check-cacheable,akamai-x-get-true-cache-key,akamai-x-get-cache-key,akamai-x-serial-no,akamai-x-get-request-id
     Expected: Response code is one of "200"
     Actual: Response code: "200"
        Status: Passed
```

問題なくテストを実施することができ、正常であるかの確認の判断を簡単に行うことができるようになります。

このようにAkamai Test Centerを利用することで、ステージングでの動作確認の自動化を行うことができ、CI/CDにも組み込める施策を検討することができます。

おそらく一般的なテストケースを目的とした確認ではAkamai Test Centerではなく、既存で導入済みのテストツールを利用したいことも多いかと思います。
例えば、PostmanやJestなどを利用した動作確認です。

- [Postman](https://www.postman.com/)
- [Jest](https://jestjs.io/ja/)

今回は、様々なテストツールがある中で個人的におすすめの、簡単に使い始めることができるStep CIも紹介します。

## Step CI とは

Step CIは、APIのテストと監視を自動化するオープンソースツールです。

- [Step CI — Open-source API-Testing Framework](https://stepci.com/)

シンプルなコマンドラインインターフェースで、REST APIだけでなく、GraphQLやgRPCなど幅広い種類のAPIに対応しています。
テストケースを記述したYAMLファイルに基づいて、自動的にAPIテストを実行でき、豊富なテストの種類: リクエスト/レスポンスの検証、パフォーマンステスト、セキュリティテストなど、様々なテストを実行できます。
Node.js、Docker、GitHub Actionsなど、様々な環境でも実行が可能です。
セルフホスティングした環境でも利用することができるため、送信元IPを固定しなければならない環境にも適しています。


### インストール

本記事ではmacOS環境にてセットアップを行います。

```
brew install stepci
```

デフォルトのまま利用すると匿名の利用データが収集されるため無効にします。

```
export STEPCI_DISABLE_ANALYTICS=true
```

コマンドが動作するか確認をします。

```
stepci --version
2.8.0
```

サンプルのテストコードを記載します。

```yaml:workflow.yml
version: "1.1"
name: Status Check
env:
  host: example.com
tests:
  example:
    steps:
      - name: GET request
        http:
          url: https://${{env.host}}
          method: GET
          check:
            status: /^20/
```

記載したテストコードを実行してみます。

```
stepci run test.yaml

 PASS  example ⏲ 0.969s ⬆ 147 bytes ⬇ 1024 bytes

Tests: 0 failed, 1 passed, 1 total
Steps: 0 failed, 0 skipped, 1 passed, 1 total
Time:  0.985s, estimated 1s
CO2:   0.00045g

Workflow passed after 0.985s
```

テストが行われ、問題なくコンテンツへのリクエストが行われたことが確認できました。

### テストコードを作成する

Akamai CDNへのテストコードを記載します。
実行する端末では対象のHostはすでにStaging環境へのSpoofingを行っている前提です。

Akamai CDNではトラブルシュートの際に活用できるPragmaヘッダーという仕組みを用意しています。

- [Pragma Headers](https://techdocs.akamai.com/edge-diagnostics/docs/pragma-headers)


```yaml:workflow.yml
version: "1.1"
name: Status Check
env:
  host: example.com
tests:
  example:
    steps:
      - name: GET request
        http:
          url: https://${{env.host}}/html/index.html
          method: GET
          headers:
            Pragma: #Pragmaヘッダーを付与する
              akamai-x-get-client-ip
              akamai-x-check-cacheable
              akamai-x-get-extracted-values
              akamai-x-get-request-id
              akamai-x-cache-on
          check:
            status: /^20/ #ステータスが20xであるか
            content-type: text/html
            ssl: #証明書が有効であるか
              valid: true
              signed: true
              daysUntilExpiration:
                - gte: 60
            headers :
              x-akamai-staging: EdgeSuite #Staging環境であるか
              x-check-cacheable: YES #キャッシュの対象であるか
              x-akamai-session-info:
                - match: "name=FOREGROUND_DOWNLOAD; value=0" #Foreground Downloadは無効であるか
                - match: "name=APPLY_TD_IN_TYPE; value=STAGING" #Staging環境であるか
                - isString: true
```

作成したテストコードが正しく動作するか確認をします。

```
stepci run workflow.yml
 PASS  example ⏲ 0.183s ⬆ 0 bytes ⬇ 0 bytes

Tests: 0 failed, 1 passed, 1 total
Steps: 0 failed, 0 skipped, 1 passed, 1 total
Time:  0.199s, estimated 0s
CO2:   0.00000g

Workflow passed after 0.199s
Give us your feedback on https://step.ci/feedback
```

Step CIで簡易的なテストを行うことができました。

テストケースはYAMLではなくJSONでも記載を行うことができます。
しかしStep CIはPathやURLのリストを実施するという機能はないため、数十のコンテンツを確認したいユースケースではテストコードが冗長になります。
Step CIは大規模なテストケースの記載には向いていないかと思われますが、簡易的なテストには手軽に導入できるツールであることがわかりました。

# まとめ

AkamaiではCDNの動作確認をStaing環境を利用することで安全に更新作業を行うことができ、動作確認の自動化も視野に入れてCI/CDのプロセスを効率化していくこともできます。
ぜひ様々なツールを活用してAkamaiを効率的に利用していただければと思います。

Akamai はCDN、セキュリティ、クラウドサービスを通じ、オンラインライフの力となり守っています。本稿でご紹介したような課題やご相談があれば、お気軽にお問い合わせください。
- [Akamai 営業担当者へのお問い合わせ](https://www.akamai.com/ja/why-akamai/contact-us/contact-sales)


# 参考リンク

- [いわなちゃんさん - CDNのテストをvarnishtestを使って行おう](https://labs.gree.jp/blog/2024/02/23009/)

# 関連記事

アカマイ・テクノロジーズ合同会社はQiitaでAkamai Cloud Computing Services関連など開発者向けの記事を掲載しております。

https://qiita.com/xenbase/items/52e2956a64cedc772bd9