見出し画像

Amazon OpenSearch ServiceをCloudFormationで作ってみた

こんにちは。
株式会社Rosso、インフラ構築運用部の遠橋です。
Amazon OpenSearch ServiceをCloudFormationで作ってみたのですが、関連サイトが少なかったので、今回ブログに書いてみました。参考にしていただけると嬉しいです。

このブログ(ハンズオン)のゴールは、実際に手を動かしながらCloudFormationを理解することにあります。
このハンズオンの対象者は、CloudFormationの初心者または初中級者に
なります。

ハンズオンの前に先ずAmazon OpenSearch Serviceとは?

Amazon OpenSearch Service(以下、OpenSearch)はざっくりいうとログ分析、ウェブサイト検索サービスです。他にも色々と機能があり過ぎるので割愛ます(詳細はOpenSearchとは - リンク参照)。

OpenSearch ダッシュボード
を使用して、大量のログ分析を可視化します。
このOpenSearch ダッシュボードはグラフィカルで個人的にすごいなあと思いました。
他にもインデックスを作成したり、色々できます。
ちょっと前までは、OpenSearchはElasticSearchと、OpenSearch ダッシュボードはKibanaと呼ばれていました。
OpenSearch ダッシュボードを利用するには、ダッシュボードにログインする必要があります(後のコードの部分で出てきますが、パラメータでユーザー名とパスワードを自身で決めて入力し、それでログインすることができます)

ここから CloudFormationの解説を含めて、ハンズオン開始!

AWS CloudFormation(以下、CloudFormation) は、インフラストラクチャをコードとして扱うことで、リソース(EC2、VPC、RDSなど色々)をデプロイ(配置、または、ざっくりいうと作成するという意味)できるサービスです。

で、実際のコードは?

AWSTemplateFormatVersion: 2010-09-09
Description: OpenSearch
Parameters:
  DomainName:
    Description: OpenSearch DomainName 
    Type: String
  DomainMasterUserName:
    Description: OpenSearch master user name 
    Type: String
  DomainMasterUserPassword:
    Description: OpenSearch master user password 
    Type: String
Resources:
  OpenSearchServiceDomain:
    Type: AWS::OpenSearchService::Domain
    Properties:
     DomainName: !Ref DomainName
     EngineVersion: 'OpenSearch_1.2'
     AdvancedSecurityOptions:
        Enabled: true
        InternalUserDatabaseEnabled: true
        MasterUserOptions:
          MasterUserName: !Ref DomainMasterUserName
          MasterUserPassword: !Ref DomainMasterUserPassword
     DomainEndpointOptions:
        CustomEndpointEnabled: false
        EnforceHTTPS: true
        TLSSecurityPolicy: Policy-Min-TLS-1-0-2019-07
     ClusterConfig:
      InstanceCount: '1'
      InstanceType: 't3.small.search'
     EBSOptions:
      EBSEnabled: true
      Iops: '0'
      VolumeSize: '10'
      VolumeType: 'gp2'
     AccessPolicies:
      Version: '2012-10-17'
      Statement:
          Effect: 'Allow'
          Principal:
            AWS: '*'
          Action: 'es:*'
          Resource: !Sub 'arn:aws:es:${AWS::Region}:${AWS::AccountId}:domain/${DomainName}/*'
     EncryptionAtRestOptions:
        Enabled: true
     NodeToNodeEncryptionOptions:
        Enabled: true

パラメータ

  1. DomainName(名前は小文字で始まり、3~28 文字で構成される必要があります。有効な文字は、a~z (小文字のみ)、0~9、- (ハイフン) です)

  2. DomainMasterUserName(マスターユーザー名は 1~16 文字である必要があります)

  3. DomainMasterUserPassword(マスターパスワードは、少なくとも 8 文字で、1 つの大文字、1 つの小文字、1 つの数字、および 1 つの特殊文字を含める必要があります)

OpenSearchは、課金が非常に高いのでできるだけ最小構成(InstanceType: 't3.small.search')でコードを書きました。
さらに料金を下げたい場合は、コードをInstanceType:'t2.micro.search'に書き換えてください。

!Refとは?

簡単にいうとパラメータまたはリソースの値(コード)を指定します。
CloudFormationでは1番よく使われる組み込み関数だと思います。

!Subとは?

特定した値の入力文字列にある変数の代わりになります。
これでは分からないので、
例えば、Amazon リソースネーム (ARN) を作成するために、
リージョンアカウントIDパラメータが変数として自動的に代入されます。
これもよく使われます。


上記がOpenSearchをYAMLで書いたCloudFormationのコードです。
コードの1つ1つの意味は書いたら膨大な量になるので以下を参照してください(まだ英語版のマニュアルしかない?ようです)


このコードをCloudFormationの所定のところでコピペして、実行すると約2
5分~30分でプロビジョニングからデプロイ
されますが、注意することがあります。
3つのCloudFormationのパラメータがコードで書かれています。
それぞれマネジメントコンソールの命名規則に沿って入力しないといけません。
なので、命名規則に沿わないでパラメータを入力すると、いざ実行してもCloudFormationのプロビジョニング後にエラーが出て、ロールバックします。
ロールバックとはデータベースにもよく出てきますが、元に戻って無かったことにするいうことです。

CloudFormationの構成要素

イメージ図

CloudFormation テンプレートとは?

まず、目的のリソースに合わせたCloudFormationテンプレートを作成します。次にスタック を作成して、プロビジョニングしてリソースがデプロイされます。
また、スタックを簡単に更新または複製することもできます。
これは変更セットでできます。
後の手順をみるとなんとなくイメージがわいてくると思います。

CloudFormationスタックセットとは?

スタックセットとは、1 つの CloudFormation テンプレートを使用して、複数のアカウント、または、複数のリージョンにリソースがデプロイできることです。


手順

手順1
手順2
手順3(YAMLを選択→テンプレート押下→コードをコピペする→テンプレートの検証を押下→OKだったらスタックの作成を押下)
手順4
手順5
手順6(パラメータをそれぞれ3つ入力する。スタックの名前を任意を入力する)
手順7
手順8(作成の完了)
手順9(コードのバージョンは1.2だが1.3に書き換えたら最新バージョンでデプロイ可能みたい)
手順10(OpenSeachダッシュボードのURLを押下する)
手順11(OpenSeachダッシュボードにログイン→パラメータで入力したDomainMasterUserNameとDomainMasterUserPasswordをそれぞれ入力)
手順12(OpenSearchダッシュボードの可視化の例)
手順13(必要に応じて、必ず最後に削除する)

注意点

CloudFormationでOpenSearchをデプロイしたら、必要に応じてCloudFormationのスタックを削除することを忘れないでください。
スタックを削除したら、OpenSearchが削除されます。
ほっといたら課金され続けるので気をつけてください。

Amazon OpenSearch Service の運用上のベストプラクティス

OpenSearchはCloudFormationでデプロイ、あるいは、手動で構築は意外と簡単にできてしまいますが、運用は非常に難易度が高いです。
ここでは数あるベストプラクティスの中からモニタリングとアラート、シャード戦略ベストプラクティスをピックアップして掲載します。

①モニタリングとアラート

・CloudWatch アラームを設定

Amazon OpenSearch Service は Amazon CloudWatch にメトリクスでCloudWatchアラームを設定できます。リソース監視などをすればAmazon OpenSearch Serviceの状態を常に監視できると思います。

・ログを有効

Amazon OpenSearch Service は、OpenSearch エラーログ、検索スローログ、インデックス作成スローログ、監査ログなどを Amazon CloudWatch Logs に送信します。Amazon CloudWatch LogsからS3バケットに転送すればよりよいログ管理になると思われます。

②シャード戦略

Amazon OpenSearch Service において、シャードはインデックスを正しく設定すると、ドメイン全体のパフォーマンスを向上させます。

・シャードとデータノード数を決定

シャードのサイズ — 各シャードが 10~30 GiB (検索の場合) または、 30~50 GiB (ログの場合) で、シャード数を設定いたします。50 GiB が最大になります。

シャード数 — データノードへのシャードの分散は、ドメインのパフォーマンスに大きな影響を与えます。ただし、シャード数よりもシャードサイズの方が重要になります。

データノードあたりのシャード — ノードが保持できるシャードの総数は、ノードの Java 仮想マシン (JVM) ヒープメモリに比例いたします。ヒープメモリの GiB あたりのシャード数が 25 個以下になるように試みます。

シャードと CPU の比率 — シャードがインデックス作成または、検索リクエストに関わっている場合、vCPU を使用してリクエストを処理をいたします。ベストプラクティスとして、1シャードあたり 1.5 vCPU を使用いたします。

・ストレージスキューを回避

ストレージスキューは、クラスター内の 1 つ以上のノードが、1 つ以上のインデックスに対して、他のノードより高いストレージを保持している場合に発生いたします。

AWSのAmazon OpenSearch Serviceはよく使うサービスですが、非常に奥が深くて私も完全に理解していないところがたくさんあります。たとえば運用面でいうと、「負荷が高いときにAmazon Kinesis Data Firehoseと連携すれば、ドメインが黄色から緑色に回復することがある」など。まだまだ勉強が必要だなと感じます。

まとめ

  • CloudFormationは初めは億劫だったが、少しコツを知れば面白くて非常に効率的にリソースを作成できる。

  • CloudFormationのOpenSearchはインターネットでも記事は少ない。

  • AWS認定試験でCloudFormationは山のように出てくるので学習になれば・・・


もし、CloudFormationでOpenSearchを作ることになるときの参考なれば、そしてCloudFormationが好きになっていただければ幸いです。