はじめに

Amazon OpenSearch Service を運用している中で、突然ドキュメントが作成されなくなったりダッシュボードにログインできなくなる、といった事象に悩まされることがしばしばありました。

本記事では、実際に発生したエラー内容とその具体的な解決策を逆引き形式でまとめてみました。

対象読者

Amazon OpenSearch Service（マネージド型）を利用している方
きめ細かなアクセスコントロール（FGAC）を有効にしている方

1. 403 Forbidden: `indices:data/write/bulk` 権限エラー

エラー内容

ECSタスクからログを転送しようとした際、以下のようなセキュリティ例外が発生するケースがありました。

{
  "error": {
    "root_cause": [{
      "type": "security_exception",
      "reason": "no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::123456789012:role/ecs-task-role, ...]"
    }],
    "type": "security_exception",
    "reason": "no permissions for [indices:data/write/bulk] and User [...]"
  },
  "status": 403
}

原因

AWSのIAMロール（ECSタスクロール等）が、OpenSearch内部のロール（all_access など）に正しくマッピングされていないことが原因です。OpenSearch Serviceでは、IAMポリシーだけでなくOpenSearch内部のセキュリティプラグイン側でのマッピングが必要です。

解決方法

OpenSearch の Dev Tools から、対象のIAMロールを all_access ロールに紐付けます。

# ECSタスクロール名部分は適宜読み替えてください。

PUT _plugins/_security/api/rolesmapping/all_access
{
  "backend_roles" : [ 
    "arn:aws:iam::123456789012:role/your-ecs-task-role",
    "arn:aws:iam::123456789012:role/another-app-role",
    ...
  ]
}

上記実行すると現在のマッピングがすべて上書きされます。既存のマッピングがある場合は、それらも含めたリストで実行してください。

設定後、GET _plugins/_security/api/rolesmapping/all_access で正しく反映されているか確認できます。

もしくは、OpenSearch の Data administration ページ内の「Roles」からも編集可能です（「all_access」で検索することで該当ロールの編集画面が出ます。Mapped users タブにてマッピングを行なってください）。

※このエラーが出ている場合、もしかしたら Dev Tools にアクセスできない状態になっている方もいるかもしれません。その場合、後述する「3. アラート設定が編集できない（Notifications plugin error）」を参考に一時的にマスターユーザーを作成してマスターユーザーで OpenSearch ダッシュボードにアクセスし、OpenSearch用のIAMを all_access ロールに紐づけることで Dev Tools が開けるようになるかと思います。

2. 400 Bad Request: シャード数の上限到達

エラー内容

インデックス作成時に以下のような「シャード数が上限に達している」というバリデーションエラーが発生してドキュメントが作成されなくなるケースがありました。

{
  "error": {
    "type": "validation_exception",
    "reason": "Validation Failed: 1: this action would add [10] total shards, but this cluster currently has [997]/[1000] maximum shards open;"
  }
}

原因

OpenSearch クラスターには、1ノードあたりの最大シャード数（デフォルト1,000）が設定されています。インデックスが細かく分かれすぎている場合や、レプリカ数が多い場合にこの上限に抵触します。

解決方法

① 古いインデックスを削除する

ログなどの場合、使用しない過去のデータがあれば削除してみてください。これによりシャード数に空きを作ることができます。

ISM (Index State Management) という機能を使用すれば、一定期間経過したインデックスを自動で削除することも可能です。ISMについては以前記事を書いたのでこちらも参考にしてみてください。

② インデックス設定の最適化

今後作成されるインデックスのシャード数・レプリカ数を抑えるように Index Template を定義します。

インデックスごとに作られるプライマリーシャード数を減らすことでシャード数の消費を抑えることができます。Dev Tools 画面にて以下クエリを実行します。

# your-index-pattern 部分は適宜読み替えてください。

PUT _index_template/your_logs_template
{
  "index_patterns": ["your-index-pattern-*"],
  "template": {
    "settings": {
      "index": {
        "number_of_shards": "1",  # 使用シャード数。ここを変える（OpenSearchのバージョンによってはデフォルトで1になっているかもしれません）
        "number_of_replicas": "1"  # レプリカシャードの数
      }
    }
  }
}

設定後、GET your-index-pattern/_settings で正しく反映されているか確認できます。

データ総量が多いのにプライマリー数が少ないと、1つあたりのシャードが巨大になりすぎて再配置（リカバリ）に時間がかかるようになります。一方でデータ総量が少ないのにプライマリー数を増やすと、オーバーヘッド（管理コスト）が増えてパフォーマンスが落ちます。そのためデータの総量に応じて適宜調整する必要があります。OpenSearch では、1つのシャードのサイズが 10GB 〜 50GB 程度に収まるように設計するのが推奨されているみたいです。

This given, a good place to start is with a number of shards that gives your index shard sizes between 10–50 GB per shard.

日次でインデックスを作成している場合、例えば一週間ごとに作るようにする等インデックスの統合を行うという手も有効です。

③ クラスターの上限を引き上げる（※非推奨）

どうしてもすぐにインデックスを作成しないといけない場合の緊急対応として、シャード数の上限値を変更するやり方もあります。Dev Tools 画面にて以下クエリを実行します。

PUT /_cluster/settings
{
  "persistent": {
    "cluster.max_shards_per_node": 2000
  }
}

シャード数の上限を増やしすぎると、OOMエラーの発生リスクが上がったり検索パフォーマンスが低下する恐れがあるのであくまで緊急時の対応としてください。

3. アラート設定が編集できない（Notifications plugin error）

事象

AWSマネジメントコンソール上のOpenSearch UIでアラートを編集しようとすると、以下のエラーが出て保存できないことがあります。

Notifications plugin is not installed
Install the notifications plugin in order to create and select channels to send out notifications.

対応方法

OpenSearch側のUIの不具合または制限の可能性があるため、OpenSearch Dashboards から直接編集を行います。

ただし、IAM権限のみで運用していてマスターユーザーを無効化している場合、Dashboards にログインできないことがあります。その場合は以下の手順で一時的にログインします。

マスターユーザーの一時作成:
AWSコンソールの「セキュリティ設定」→「きめ細かなアクセスコントロール」にて、「マスターユーザーを作成」を選択。任意のユーザー名/パスを入力します。
Dashboardsへログイン:
ドメイン詳細に記載されている「OpenSearch Dashboards URL」へアクセスし、作成したユーザーでログインしてアラート設定を修正します。
元に戻す:
作業完了後、セキュリティ設定を元の「IAM ARN をマスターユーザーとして設定」に戻します。

マスターユーザーを「IAM ARN」から「ユーザー名/パスワード」に切り替えると、それまで動いていたログ転送が一時的に403エラーになる可能性があるため、深夜帯やメンテナンス時間に行うことを推奨します。

4. User: anonymous is not authorized (Dashboardアクセス不能)

事象

OpenSearch Dashboards にアクセスしようとした時に、以下のメッセージが表示されて拒否されるケースがありました。

User: anonymous is not authorized to perform ...

原因

ドメインのアクセスポリシーにおいて、現在の接続元（IPやユーザー）からのアクセスが許可されていません。

解決方法

一時的にアクセスポリシーの Principal をフルオープン（*）に設定し、アクセスを確認します。なおセキュリティ保護のため、Principal を * にするのは検証用ドメインかつIP制限がかかっている場合に限定してください。

AWSコンソールにて Amazon OpenSearch Service > Domains のセキュリティ設定を開き、「編集」ボタンを押してアクセスポリシーのJSONを以下のように修正してください（※編集前のJSONをどこかにメモしておき、作業後は必ず元に戻してください）。

# your-domain-name 部分は適宜読み替えてください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:ap-northeast-1:123456789012:domain/your-domain-name/*",
      "Condition": {
        "IpAddress": { "aws:SourceIp": "YOUR_OFFICE_IP/32" }
      }
    }
  ]
}

これでダッシュボードにアクセスできるはずです。

まとめ

私が遭遇したエラーとその対応例を記載しましたが、他にも良い対応方法があるかもしれません。別の対応方法を見つけたり、上記以外のエラーに遭遇した場合にはまた記事を書こうと思います。

この記事がお役に立てば幸いです。

参考サイト