NTTデータの奥村です。
いきなりですが、AWSのサービスアップデートって確認するのは難しいですよね。
ここ数か月のAWS社から発表されたアップデート数は、平均して毎日10件ほどとなっており、毎日これだけの膨大な内容を追っていいくのはなかなか大変骨が折れることですし、気づかずに重要なアップデートを見逃すこともあるのではないか？と思います。
本記事では、弊社内での大切なアップデートを見逃さないためのちょっとした工夫について、紹介したいと思います。
弊社の仕組みの全体像
弊社では、下記のように複数のAWSサービスを組み合わせることで、RSSフィードから情報を収集する仕組みを実装しています。具体的な構成については、以下の図をご覧ください。
全体の大まかな流れとしては下記のようになっています。
- 日次でAWSの公式RSSフィードから情報を取得する
- 取得した結果をDynamoDBに保存する
- サービス発表後、2日以上経過した際に、XからSearch Tweets APIを使ってツイート数を取得する（XのAPIはこちらのように複数のプランがありますが、参照処理が実施できるのが有償のBasic以上となりますので、ご注意ください）
- DynamoDBからOpenSearch ServiceへゼロETL機能（DynamoDBに格納されたデータをニアリアルタイムでOpenSearch Service内のデータストアに格納し、OpenSearch Serviceで利用できるようになる機能）を利用して、データを送信する
- OpenSearchダッシュボードでツイート数が多い順に表示される
弊社として特に工夫している個所は、Xのツイート数の情報を組み合わせている部分です。発表されたサービスアップデートを自動的にXのツイート数が多い順に並び替えており、多くのユーザーが関心を持っているサービスアップデートがなんであるかを一目で確認できるようにしています。これにより、重要なサービスアップデートの見逃しを防いだり、インパクトが大きいものを素早く見つけることができるようにしています。
実際のAWSアップデートの一覧画面
また、OpenSearchの全文検索機能も利用できますので、特定のAWSサービスに関するアップデートについても簡単に検索することが可能です。
「EC2」というキーワードで絞り込んだ様子
失敗談
文字として起こしてしまうと、きれいな表現となっているのですが、実はこの構成で安定運用を行うまでに様々な問題が出ていましたので、少し失敗談をお話ししたいと思います。
DynamoDBとOpenSearchのゼロETLが機能しない
LambdaがDynamoDBにRSSの情報を格納していたのですが、待てど暮らせどOpenSearchにデータが入ってこないという事象が発生しました。公式ドキュメントに前提条件として記載がされておりますが、下記2つの設定がされているDynamoDBに必要です。
- DynamoDB Streamsの有効化
- ポイントインタイムリカバリの有効化（スナップショットを使用している場合）
また筆者の環境では上記の前提を満たしているのにもかかわらず、ゼロETLが機能しない状況も起きました。その際にはゼロETLを実現するパイプラインのログを確認すると解決のヒントが含まれていることがあります。ログはCloudWatch Logsから確認可能です。
パイプラインに設定されているCloudWatch Logsの設定箇所
筆者の環境では、CloudWatch Logsに「Request failed: [security_exception] no permissions for [cluster:monitor/state] and User [パイプラインの実行IAMロールのARN]」というエラーメッセージが表示されており、DynamoDBのデータをOpenSearchのインデックスに取り込む際の権限不足が発生していました。
この場合は、別の公式ドキュメントに記載のステップ3内のシナリオ1を実施する必要があります。ただこちらの投稿のほうがわかりやすいかもしれないので併せて紹介いたします。具体的にはOpenSearchのall_accessというRoleのBackend rolesにパイプラインの実行IAMロールのARNを指定する必要があります。パイプラインの実行IAMロールがOpenSearchに関する権限を持っていないとゼロETLの取り込み処理が失敗するということです。
Backend_roleへのIAMロールの指定方法
Backend rolesを利用する理由に関する補足
ゼロETL機能では、下図のようにゼロETLのためのパイプライン実行用のPipeline RoleというIAMロールにて、Opensearch Service内のデータストア（Index）にデータを格納していきます。
Amazon OpenSearch Ingestion のロールとユーザーの設定より引用
しかし、OpenSearchでは直接IAMロールにOpenSearchの操作権限を付与することは出来ません。そのため、一度Backend rolesを挟むことでゼロETL実行用のIAMロールにOpenSearchの操作権限を付与することを実現しています。
Amazon OpenSearch Serviceセキュリティベストプラクティスのスライド29より引用
こうした前提を満たした後に数分待機すれば、OpenSearch Serviceへの転送が開始されます。
また正常に動作しているかを確認するため、CloudWatchで監視する必要もあります。公式ドキュメントには監視対象の推奨メトリクスがありますので、こちらを参考に今回のような構成であれば、最低でも以下のメトリクスについてはアラームを設定しておくことをおすすめします。
- dynamodb-pipeline.dynamodb.exportJobFailure.count
- dynamodb-pipeline.opensearch.documentErrors.count
- dynamodb-pipeline.BlockingBuffer.recordsWriteFailed.count
OpenSearch ServiceとしてServerlessを採用したが高コストに
以下が最小構成での東京リージョンの費用比較となります。もちろん可用性の面での差はあるのですが、内部利用などの高い可用性を求めないケースで、コストを抑えたいというときにServerlessは最低構成で見たときに、5倍以上のコストとなってしまいます。
| 種類 | コスト | 前提 |
|---|---|---|
| マネージド型クラスター | 0.056 USD/時間 | t3.small.search構成 |
| Serverless | 0.334 USD/時間 | 最低の1 OCU構成 |
Amazon OpenSearch Service の料金より
さらに、OpenSearch Serverless は、冗長スタンバイノードなしでコレクションを起動できる開発テストオプションも提供します。このデプロイモードでは、インデックス作成で 0.5 OCU、検索で 0.5 OCU となるため、さらにコストを半減できます。
ですが、これだけでOpenSearch Serverlessが高いと判断してしまうのはいささか早計です。この後の失敗談で紹介する予定ですが、仮に内部利用でもあっても最低限の可用性は求められますので、可用性のレベルをもう少し合わせた状態でコストの再比較をしたいと思います。
OpenSearch Serverlessでの最低の1 OCU構成にするためには、下記のようにアクティブレプリカを無効化する必要があります。
※ Amazon OpenSearch Serverless is now generally available!の記事を参考に筆者が作成
アクティブレプリカが無効化されると、1つのアベイラビリティゾーン（AZ）に配置される構成となりますので、マネージド型クラスターも1AZ構成で比較します。
またOpenSearch Serverlessは、AWSが基盤となるインフラストラクチャを完全に管理するフルマネージドサービスであるため、分散システムにおけるクォーラムという概念を利用者が意識する必要もなくなっています。そのため、マネージド型クラスターでは意識しなければいけないクォーラム損失（クラスターを組んでいる複数のノード間の投票による状況判断ができない状況）による可用性低下は発生しません。クォーラム損失を防ぐには最低3台のノード（もしくは1台の専用マスタノード＋2台のデータノード）で構成する必要があることから、条件を同一にするため、マネージド型クラスターでは3台のt3.small.searchが必要と定義します。この条件のもとに再度コストを比較した結果が下表となります。先ほどよりも金額差は少なくなりましたが、それでもServerlessのコストはマネージド型クラスターの2倍近くとなりました。
| 種類 | コスト | 前提 |
|---|---|---|
| マネージド型クラスター | 0.168 USD/時間 | t3.small.searchを3台構成 |
| Serverless | 0.334 USD/時間 | 最低の1 OCU構成 |
Serverless＝安いというイメージでServerlessを選定してしまうと、想定以上の高額になることもあり得ますので、コストを重視される場合はマネージド型クラスターの利用も検討いただければと思います。
OpenSearch Serviceの全データロスト
実は上記のような可用性を意識する構成を考えるきっかけとなる障害を起こしていました。コストを最小限に抑えようとマネージド型クラスターのt3.small.searchを1台で運用していたところ、ある時急にOpensearchダッシュボードにログインが不可となりました。原因は自動復旧機能によるノード入れ替えが発生していたことでした。レプリカが存在しない1台構成だとデータ復旧ができない仕様ですので、これによる認証情報を含む設定情報も消失が起きてしまっていました。筆者は以下の手順で復旧を行いました。
- マスターユーザの再作成
- 自動的なスナップショット取得はしていたため、障害発生時間前のスナップショットをリストア
- ユーザの再作成
- all_accessのRoleのBackend rolesにDynamoDBとのゼロETLパイプラインの実行IAMロールのARNを再指定
スナップショットのリストアは上記リンクの通り、GUIにて実施し、データ量が少なかったこともあり、数秒で完了しました。しかし長期間の運用をした際には、データ量増加に伴い、リストア時間が長期化することも予測されます
1台構成でもデータの消失は起きないだろうと安易に考えていたため、原因に気づくのが遅れ、復旧に時間がかかってしまいました。この苦い経験から、内部利用だとしてもクォーラム損失の対策も含めて、3台での構成として運用を続けています。またt系インスタンスはメモリ量が少ないことから、挙動が不安定になりやすいので、利用が推奨はされておりません。そのため、内部利用だとしてもt系インスタンス以外を選択することをご検討ください。
おわりに
本記事では、弊社で実施しているAWSアップデートの情報収集の仕組みやそこでの失敗談を紹介しました。この記事が皆様のお役に立てば幸いです。
仲間募集中です！
NTTデータ クラウド&データセンタ事業部では、以下の職種を募集しています。
- プライベートクラウドコンサル/エンジニア
- デジタルワークスペース構築／新規ソリューション開発におけるプロジェクトリーダー
- IT基盤(パブリッククラウド、プライベートクラウド)エンジニア
- パブリッククラウド/プライベートクラウドを用いた大規模プロジェクトをリードするインフラエンジニア