Amazon OpenSearchのコスト最適化とZeroETLへの期待 / Amazon OpenSearch Cost Optimization and ZeroETL Expectations

弥生株式会社 もくテク
AWS re:Invent 2024 参加報告会（2025/01/29）
https://connpass.com/dashboard/

Transcript

1. Amazon OpenSearchのコスト最適化と ZeroETLへの期待
2. © 2025 Yayoi Co., Ltd. All rights reserved. 2 自己紹介 開発本部 サービスプラットフォーム部 エンジニア 今泉 和馬 （いまいずみ かずま） 弥生での業務 AWSのセキュリティとガバナンス オンプレ - AWSのネットワーク運用保守 好きなアマゾン ウェブ サービス（AWS）サービス AWS Control Tower 、AWS Transit Gateway、 Amazon OpenSearch Service 職歴 2018 ~ 2020：独立系SIer 2021 ~ 2022：APNパートナー企業 2023 ~ : 弥生
3. ◼ 初海外・初re:Invent ◼ ずっと楽しい ◼ 睡眠時間が短い ◆ 帰ってきて体調不良（溶連菌→気管支炎のダブルコンボ） ◼ ワークショップをメインにセッションに参加 弊社でも導入しているOpensSearchのコスト最適化の セッションの内容について ◼ [ANT310] Amazon OpenSearch Service による低コストのログ記録と監視 re:Invent現地初参加しました～
4. Amazon OpenSearch Serviceの概要 ◼ OpenSearchベースの完全マネージドサービス ◼ コスト、セキュリティ、スケーラビリティを最適化 ◼ リアルタイムアプリケーション監視、ウェブサイト検索、インタラクティブロ グ分析などに活用可能
5. 弊社利用例
6. OpensSearchのコストについて •基本 • データノードで利用するインスタンス • インスタンスタイプ×利用するノード数 • ストレージ料金 • EBS • OR1インスタンス利用であればS3 •オプション • UltraWarmデータノード • ウォームデータストレージ (低頻度アクセス データ) • コールドデータストレージ(長期アーカイブ データ) • 専用マスターノード • インスタンスタイプ×利用するノード数
7. ◼ レプリカシャードを利用で、単純に保管するログの倍のインスタンスが必要 ◆ レプリカシャードとはプライマリシャードが壊れたとき用のバックアップ ◼ インスタンス毎に最大容量が決まっているので、容量が増え続けるだけでスペッ クの高いインスタンスタイプを選択する必要がある ◼ 3つのストレージティア (ホット、ウルトラウォーム、コールド) を提供 ◆ ホットストレージに約 2.5 TiB ある場合にUltraWarmのコストメリットが見込まれる ◆ ポリシーベースの自動化で、ログのライフサイクルを最適化可能 ◆ UltraWarmを利用するにもインスタンスの費用はかかるので注意 ログの保管量の増大に伴い、コストと可用性のバランスが重要 コストのかかると思われる要因
8. ◼ re:Invent2023で発表 ◼ 料金パフォーマンスが最大 30% 向上し、Amazon S3 を使用してイレブンナイン の耐久性が実現 ◆ EBS ボリュームをプライマリストレージとして使用し、データが書き込まれるとすぐS3 に同期 的にコピー ◼ 高い耐久性と共に、インデックスへのスループットも向上 ◼ プライマリでのみドキュメント操作が実行されるため、書き込みレイテンシが低 い ◆ 弊社環境でもOR1インスタンスを今季から利用 ◆ 統合環境に関してはノード数見直しとOR1インスタンスを利用しコスト50%減 ◼ これまでレプリカシャードで利用していたEBSボリュームをS3に置き換えること ができる OR1インスタンス
9. ◼ 2.15以前の既存ドメインは他のインスタンスタイプからOR1インスタンスへ切り 替えることができないため、スナップショットから復元するなど移行が必要 ◼ レプリカシャードは0に設定するインデックスの設定が必要 ◆ データは Amazon S3 から自動的に復元されるが、修復操作中は一部のデータアクセスができ なくなる ◆ アクティブに書き込まれていないインデックスの検索に高可用性が必要な場合レプリカを利用 しつつ、アクティブに書き込まれなくなったインデックスは0にするという形でログのライフ サイクルを設定する必要はある OR1の注意点
10. ◼ OpenSearch Service からS3 上のデータにクエリを実行できる Direct Query が 利用可能 ◼ 複雑な抽出、変換、ロード (ETL) パイプラインを構築する必要がなくなる ◼ OpenSearch Service と Amazon S3 ストレージの両方にデータを複製するコス トがかからなくなる ◼ 現状のゼロETLは2種類 ◆ Amazon OpenSearch Service zero-ETL integration with Amazon S3(re:Invent2023で発表) ◆ Amazon OpenSearch Service zero-ETL integration with Amazon Security Lake. (re:Invent2024で発表) ◼ 弊社でも利用を検討 ◼ OpenSearch ドメインはバージョン 2.13 以上 ゼロETL
11. 弊社で利用するなら。。。
12. ◼ EBSボリュームを気にする必要がなくなることはすごくいい ◆ ボリュームが増える→インスタンスの過剰スペックを選択しなければならないことにおびえな くていい ◼ Dashboardが準備されていたりするので使いやすい ◼ 高速にクエリする方法が3つ準備されている ◼ 普通の状態と検索するよりは遅かったり、何をカラムとして指定するかなど検討 することは増える ゼロETLの操作感・所感 https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2024_Amazon-OpenSearch- Service-Best-Practice-Logging_1210_v1.pdf から引用
13. ◼ Skipping indexes ◆ S3 に保存されたデータのメタデータのみをインデックス化するオプション ◼ Materialized views ◆ 集計などの複雑なクエリを使用するダッシュボードの Visualize を作成するときに使うオプ ション ◼ Covering Indexes ◆ 指定されたカラムのデータを全てインデックス化。ストレージを多く使うが、パフォーマンス 効果は最も高いオプション 高速クエリ Skipping Materialized views Covering Indexes ユースケース クエリ Visualize作成 ほぼOpensSearchの機 能が利用可能 パフォーマンス 15-30 s 1-5 s 1-5 s インデックス作成有 無 メタデータのみ Dashboard作成などの Aggregationで利用 新しくインデックスを 作成 ストレージ保存 小 小 大
14. ◼ ログの用途に合わせて使い分けが必要 ◆ 全部をゼロETLに置き換えることは難しいので、S3 Tablesとかと連携してEBSと遜色なく検索 できればいいなあ ◼ 新しいサービスに触れたのはすごくよかったです！ ◆ 必要な情報やサンプルログで操作でき、日本で利用を検討できる状態に持って行けたのはすご くよかった まとめ
15. ご清聴ありがとうございました！