こんにちは、テクニカルサポートエンジニアの宮本です。
最近 API Server をダウンロードされた方々から、「冗長化構成する場合の手順はありますか？」、「API ServerとALBを使った構成方法は？」など API Server を AWS のALB を用いた構成で検討されているといった旨の連絡をよく受けるようになりました。
AMI 版を利用することでさくっと構成は組めるのですが、設定情報を外部DBに保存したり、AMIライセンスの制約上インスタンスのイメージコピーはせずに2つ目の API Server を用意したり、セッション情報の管理方法を変更したり、引っかかりポイントがいくつかあります。
そういったところも含めて、今回は 2台の API Server を ALB （ロードバランサー）を使った構成方法でご紹介したいと思います。
構成
冒頭でもお伝えしたように、ALB 経由の API Server マルチインスタンス構成を構築してみます。
おおまかにやることは以下内容になります。
それでは実際に構築していきましょう。
API Server の準備
今回は インストールとライセンスの部分を省略したいので、AMI 版 API Server を使います。
AMI 版 API Server の用意方法は下記記事に書いてありますので参考にしてください。（数ステップで用意できます！ ）
www.cdatablog.jp
EC2 のインスタンス一覧に追加され起動されましたら、「https://[IP] or [Public DNS]」でアクセスしてみます。
アクセスしたら最初にログイン画面が表示されますので、
- ユーザー：admin
- パスワード：EC2のインスタンスID
を入力しログインします。
次は API Server の設定情報を外部DBに保存するよう設定していきます。
API Server ログインユーザーのパスワード変更
まずはロードバランサー配下の全てのインスタンスで共通のパスワードを使用するようパスワードを変更します。
SSH でインスタンスに接続し、下記ファイルを開きます。
/opt/apiserver/etc/cdata.realm
赤枠部分を任意のパスワードに変更します。今回は「ami-test」としました。
これでパスワード変更が完了で、次は設定情報を外部のDBに保存する設定を行っていきます。
API Server の設定情報を外部DBに保存
今時点で最新の V21 API Server の場合、設定するファイルは下記になります。
- /opt/apiserver/webapp/apiserver.xml
変更内容は、APP_DB のブロックのコメントを外したあと、APP_USERS も追加して接続情報を設定します。
<Call name="setInitParameter"> <Arg>APP_DB</Arg> <Arg>jdbc:mysql:Server=MySQLServer;Port=3306;Database=mysql;User=user;Password=password</Arg> </Call> <Call name="setInitParameter"> <Arg>APP_USERS</Arg> <Arg>jdbc:mysql:Server=MySQLServer;Port=3306;Database=mysql;User=user;Password=password</Arg> </Call>
次に"jdbc:mysql:～"に設定情報を保存したい外部DB の接続情報を設定します。
※ちなみに V20 をご利用されている場合は、jetty.xml と apiserver.xml の2つを変更しますので、以下の記事を参考にしてください。
APIServer AMI の設定情報を管理用DBに保持する方法 - CData Software Blog
なお、MySQL 以外の場合はそれぞれのRDB に合った接続文字列を指定してください。
これで設定が完了したので、API Server を再起動します。
~ # systemctl restart cdata-apiserver ~ #
ログイン後、先ほど設定した外部DB を参照するといくつかテーブルが作成されていると思います。
API Server のリソース作成
それでは API Server でリソース作成をしていきましょう。
SETTINGS → Connection で自分が使うデータソースのアイコンをクリックし、接続設定をしていきます。
接続できましたら、Resources タブよりどのテーブルのエンドポイントを生成するのかを設定します。
設定が完了したら、ロードバランサー部分を設定していきます。
ドメイン取得
ロードバランサーに設定するため、Route53 などでドメインを取得します。 取得方法は以下の記事をご参考ください。
www.cdatablog.jp
ターゲットグループの作成
ALB から利用するターゲットグループを作成します。最初は ALB とインスタンスは 1対1 の構成で進めます。 （EC2のメニューからいける）
Instances を選択し、このターゲットグループ名を設定します。
API Server へのプロトコルに HTTPS を選択します。AMI 版はデフォルトでは HTTPS での接続となっていますが、設定ファイルの変更で HTTP への変更も可能です。
Health Check Path には今回は「/login.rst」を指定し、画面下部にある NEXT ボタンをクリックします。
次に対象のインスタンスをターゲットグループに指定します。
指定したら画面下部の CREATE ボタンをクリックでターゲットグループの設定が完了です。
アプリケーションロードバランサー（ALB）を作成
ロードバランサーの管理画面を開き、作成ボタンをクリックします。
ALB(Application Load Balancer) を利用しますので、ALBにある Create ボタンをクリックします。
ロードバランサー名を指定します。Scheme、IP はデフォルトのままで OK です。
次にローティングの設定です。使用するサブネットを指定します。
セキュリティグループは API Server で使っているセキュリティグループを設定します。
リスナーについては、外部から ALB に HTTPS で接続してもらうようにし、Deafult action に先ほど作成したターゲットグループを指定します。
Secure listener settings は、取得している証明書を設定します。今回は Route 53 で取得したものをセットしています。
Create ボタンをクリックしてALBの作成が完了となります。
Route 53 でサブドメインを設定
使用するサブドメインを設定します。
Route 53 にてホストゾーンから対象のドメインをクリックします。
レコードを作成をクリックします。
エイリアスをクリックしてサブドメインを設定します。トラフィックのルーティング先にはALB を選択します。そうしますと、リージョンとロードバランサーを選択できるようになりますので、それぞれ対象のリージョン、作成したロードバランサーを選択します。
セキュリティグループのインバウンドルールの設定
HTTPS でのアクセスはALBからのみ許可するようセキュリティグループのインバウンド設定を変更します。
インバウンドルールにあるポート：443 にアクセスできる対象が特に制限の無い 0.0.0.0/0 となっています。
この状況では ALB を通さなくても API Server のコンソール画面が表示できてしまいますので、ソースは自分のセキュリティグループを指定し自己参照で指定します。ALB でも同じセキュリティグループを指定しているので、ALB からのアクセスのみHTTPS でアクセスできるようになりました。
以上で設定が完了となります。
これでインスタンスが1台であるもの、ALB 経由の API Server を構成しました。
それでは API Server にアクセスしてみましょう。
シングル構成の API Server にアクセス
先ほど Route53 で指定したサブドメインを使ってアクセスしてみます。
https://apiserver-ami.cdatajp.com/
コンソール画面には接続できました。では、生成したエンドポイントを
Postman から叩いてみます。
ちゃんとレスポンスが返ってきました。
ということで、1台目 API Server を元に2台目 API Server を作成していきましょう。
2台目 API Server を作成
1台目の API Server から「同様のものを起動」を選択します。（AMIの場合、インスタンスIDとAMIライセンスが紐づいているのでイメージコピーでの複製はできません）
デフォルトではパブリックIPが無効になってるので有効にしていきます。右にある「インスタンスの設定の編集」をクリックします。
パブリックIPを有効に変更したら、「確認と起動」をクリックしてインスタンスを起動します。
作成されたインスタンス名はもとにしたインスタンスと同名でセットされているので、識別できるように変更しておきます。
では1台目の API Serverと同様の変更を行っていきます。
SSH で2台目の API Server にアクセスして、「API Server ログインユーザーのパスワード変更」と「API Server の設定情報を外部DBに保存」を行います。
設定内容は全く一緒です。
ターゲットグループにインスタンス追加
設定が完了したら、ALB から参照しているターゲットグループに2台目のインスタンスを追加してあげます。
ALBのスティッキーセッションを有効化
最後にロードバランサーの設定でスティッキーセッションを有効にします。
有効にすることでアクセス先のターゲットがクライアント（ブラウザ）ごとに固定されるので、セッションIDが不一致となってアクセスできないような事象が発生しないようになります。もしセッション情報を外部で共通的に管理しているような場合は不要です。
まずターゲットグループを開いて Attributes から Edit をクリックします。
Stickiness にチェックを入れ、type はどちらでも可ですが今回は Load balancer generated cookie を選択して保存します。
これで2台構成の設定が完了です！
マルチインスタンス構成の API Server にアクセス
では1号機、2号機の API Server インスタンスを起動させておき、コンソールにアクセスしてみましょう。
下記URLにアクセスしてみます。
https://apiserver-ami.cdatajp.com/
そうしますと、先ほどのシングル構成の場合と同じようにログイン画面が表示されますのでそのままログインし、設定情報を確認してみると、ちゃんと引き継がれているのがわかります。
Postman でリクエストしてみても同じようにレスポンスが返ってきます。
おわりに
いかがでしたでしょうか？AMI版 API Server を使うことで少ないステップでマルチインスタンス構成を組むことができました。次は Auto Scaling 構成なども試してみたいと思います。
今回ご紹介した構成はインストール型の API Server でも実現可能です。こちらは 30 日間のトライアル利用が可能ですので、是非お試しください。
