MarkLogicをAWSにデプロイしてみた

はじめに

こんにちは。SRE2課の福島です。

先日、以前から持っていたAlexaに追加でSwitchBotハブミニを買い、
リビングの電気を声でオン、オフできるようにしました。便利ですね～。

今回は、MarkLogicをAWSにデプロイする方法をブログにまとめたいと思います。

そもそも、MarkLogicとは...

MarkLogicサーバーは、NoSQLと、信頼性の高いエンタープライズデータ管理機能の両方を備えたマルチモデルデータベースです。
また、データハブの基盤として最適なデータベースです。

引用：https://jp.marklogic.com/product/marklogic-database-overview/

マルチモデルデータベース？データハブ？

マルチモデルデータベースとは、
複数のデータモデルをネイティブに格納することができるデータベースです。
そして、統一されたデータガバナンス、管理、アクセスが備わっています。

参考：https://www.marklogic.com/blog/multi-model-database-jp/

データハブとは、

分断（サイロ）されたデータをハブ＆スポークのアプローチで統合することです。

引用：https://www.marklogic.com/blog/multi-model-database-jp/

こんな感じで、ハブにデータを統合するイメージですね。

なんだか、SwitchBotハブミニに似てますね。

これって、必要？

世の中に変化はつきものですが、ずっと変わらないこともあります。業務、業界を問わず、データの「サイロ」（分断）は依然として存在していると言ってよいでしょう。そしてこれらのデータサイロにより、企業や官公庁などの世の中の変化に対する対応が遅くなっています。データサイロがこの問題の根本的原因である場合があります。

引用：https://www.marklogic.com/blog/data-lakes-data-hubs-federation-jp/

上記の通り、データの分断（サイロ）が根本的な原因で企業や官公庁などの
世の中の変化に対する対応が遅くなっている場合があるみたいです。

そこで、データを集約して、統一されたデータガバナンス、管理、アクセスできる
ソリューションが必要になり、そこで登場するのがMarkLogicというわけですね。
※スポークにあるデータの管理の仕方は、まちまちなので、
　統一して管理ができる点がハブ（MarkLogic）の良さなのかなと思います。

MarkLogicデプロイ用のCloudFormation

実は、AWSにMarkLogicをデプロイするためのCloudFormationが用意されているので、
テンプレートを実行するだけでMarkLogicのデプロイが出来ます。

テンプレートの種類

テンプレートには、2種類あります。

①VPC込みでMarkLogicを構築してくれるテンプレート
②既存のVPCを利用してMarkLogicを構築してくれるテンプレート

それぞれのテンプレートは、以下からダウンロードできます。
https://developer.marklogic.com/products/cloud/aws/

今回は、②のテンプレートかつバージョン10を利用します。

構成図

構成図は、以下の通りです。

引用：https://docs.marklogic.com/media/apidoc/10.0/guide/ec2/CloudFormation/images/AWSregion.gif

作成されるリソース一覧

①EC2 × 3台（台数は、テンプレートを展開する際に指定可能）
※プライマリENI、EBS（システムボリューム）込み。
②セカンダリENI × 3つ（EC2の台数に応じて作成）
③EBS（データボリューム） × 3つ（EC2の台数に応じて作成）
④AutoScalingグループ × 3つ（EC2の台数に応じて作成）
⑤起動設定 × 3つ（EC2の台数に応じて作成）
⑥SNS × 1つ（AutoScalingのライフサイクルフック用）
⑦Lambda × 2つ
⑧DynamoDB × 1つ

ここから本題

前置きが長くなりましたが、ここからAWSにMarkLogicをデプロイする方法についてです。

やることは以下の通りです。
①事前作業（VPC、サブネット、NatGateway、AMI利用の同意、IAMロール作成）
②テンプレートの展開
③動作確認

参考：https://docs.marklogic.com/10.0/guide/ec2/CloudFormation

事前作業

まず、CloudFormationを展開する前に以下のリソースを作成しておきます。

①VPCの作成
②パブリックサブネットの作成 × 3つ
③プライベートサブネットの作成 × 3つ
④NatGatewayの作成 × 1つ
⑤AMIの利用規約の同意
⑥EC2に付与するIAMロールの作成
※今回は、構成図に載っているVPCエンドポイントは作成しません。

また、AutoScaligのイベント通知が必要な場合、事前にSNSを用意する必要があります。
※今回は、設定を行いません。
　また、AutoScaligのライフサイクルフック用のSNSは、テンプレート内で作成されます。

ネットワークリソースの構築

VPC、パブリックサブネット、プライベートサブネット、
NatGatewayの作成手順は、割愛させていただきます。

AMIの利用規約の同意

事前に同意しておかなければ、AMIを利用することができず、
AutoScalingによるAMI起動が失敗してしまうので、事前に利用規約に同意しておく必要があります。

◆AMI起動失敗エラー

バージョン10の場合、以下にアクセスし、同意します。
https://aws.amazon.com/marketplace/pp?sku=djonw5gxpw8bpwnrtdbd0x2mj

EC2に付与するIAMロール作成

ドキュメントに記載がなかっため、推測になりますが、
とりあえず、以下の権限を付与すれば、MarkLogicのサービスを起動することができました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "dynamodb:*",
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:AttachVolume",
                "ec2:DescribeInstances",
                "ec2:DescribeVolumes",
                "ec2:DescribeImages",
                "ec2:CreateTags"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "sns:*"
            ],
            "Resource": "*"
        }
    ]
}

CloudFormationの展開

テンプレートを使って、デプロイします。

パラメーターを入力したスタックを作成し、ステータスが「CREATE_COMPLETE」になればOKです。

実は...

大した話ではないですが、メインのテンプレートから２つのテンプレートをネストしています。
※もう１つのテンプレートでは、VPCスタックとVPCエンドポイントスタックが追加で作成されます。

マネージドENIスタック

セカンダリENIを作成するLambda関数を作成するスタック

ノードマネージャスタック

Auto Scaling Groupのライフサイクルイベントにフックされ、各クラスターノードを管理するLambda関数を作成するスタック

動作確認

EC2のステータスチェックが2/2になっていることを確認後、
3台のEC2が以下の画像の通り、データボリュームがアタッチできていることを確認します。

データボリュームがアタッチされていないインスタンスがあったら、
AutoScalingグループを修正する必要があります。

原因

これは、EC2のAZとアタッチしようとしているEBSのAZが異なっていることが原因です。
なぜ、差異が出る場合があるかというと、
CloudFormationで指定したプライベートサブネットがサブネットIDで昇順に並べ替えられるためです。
※テンプレートは、1a,1c,1dの順にサブネットが指定されることを前提に作成されています。

私の場合、1a,1c,1dの順にサブネットを指定したのですが、
1c,1a,1dにあるサブネット順に並べ替えられてしまいました...

解決方法

AutoScalingグループのサブネットの設定を以下の組み合わせになるように変更します。

AutoScalingグループ名	サブネット
【スタック名】-MarkLogicServerGroup1-【任意の文字列】	1aに存在するサブネットを指定
【スタック名】-MarkLogicServerGroup2-【任意の文字列】	1cに存在するサブネットを指定
【スタック名】-MarkLogicServerGroup3-【任意の文字列】	1dに存在するサブネットを指定

設定を変更するとEC2が新しいサブネットで起動され、設定前のサブネットで起動していたEC2が削除されます。

再度、動作確認

3台のEC2にデータボリュームが付与されていることを確認後、
CLBのヘルスチェックを確認し、ステータスが「InService」になっていることを確認します。

CLBのステータスを確認できたら、以下のURLにアクセスすると
認証情報を求められるため、テンプレート展開時に指定したログイン情報を入力します。

http://【CLBのFQDN】:8001
※テンプレート展開後の「出力」項目の「URL」キーに記載されています。

ログインできれば、MarkLogicのコンソールにアクセスできます！

おわりに

CloudFormationのテンプレートが用意されているので、簡単に？デプロイできました！

ただ、以下の構成になっている点は、注意が必要そうです。
・セキュリティグループが「0.0.0.0/0」で開放されている。
・ELBとして、CLBが利用されている。
・ユーザーデータにMarkLogicのパスワードが平文で設定されている。

また、ポイントとしては、AutoScalingが発動しても、
データボリュームが削除されず、新しいEC2でデータボリュームが再利用される点ですね。
※データボリュームを独立させることでステートレスな構成にしてるみたいです。

ちなみに、DynamoDBは、以下の感じでEC2のメタデータを管理してます。