AWSのITコストを削減 Simpline

選ばれ続けること

 

エンジニアブログ

ホーム - エンジニアブログ - 2016年8月

ELB(Application Load Balancer)をおさわりする

2016.08.26

AWSから接続名によって接続先を切り替えられることのできる負荷分散サービス提供されました。
ApplicationLB
他にも、いろいろと追加機能がありますが、とにかく知識がついていっていないです。
ただ、いままでのELBがClassicになる瞬間というものを目の当たりにして感慨深いです。

執筆時点で既に多くの技術者の方々がApplicationLB(以下ALB※)について執筆されており
いつもの自分であれば、貪り読んでから着手するのですが、
今回は、なるべくそれらに目を通さず、夢を持った状態で触って見たいと思います。
※ALBはみんなだいすきクラスメソッドさんのブログの呼称を拝借いたしました。
打鍵が少なくて、でもなんとなく伝わる感じが良いですね。

★勝手に出来ると思い込んでいたこと★
たとえばALBのEndPointDNSに対して「*.ドメイン」みたいなワイルドカードで
Route53にCNAMEレコードを書いてあげれば
一つのALBで複数のWebサーバ名を打ち分けられるんじゃないのか
つまりnginxとかがrewriteでやっているようなことが出来るんじゃないかとおもったのですが
【結果】無理でした。
Pathベースって単語をチラ見した瞬間、なんとなく気づいていたのですが、
まあ、物は試しと思ってやったのですが、はやり、というか当然駄目でしたね。

①ALBのEndpointをDNSにCNAMEでワイルドカードで受けられるように書いてあげる
WS000022

②ALBの接続名による打ち分けを以下のように設定。Path部分には自信満々にサーバ名を記載
http://1a.XXX.com →AZが1aのWebサーバへ、http://1c.XXX.com →AZが1cのWebサーバへそれぞれ僕の夢を乗せたリクエストが飛ぶはず
※defaultは1aのdefaultWebサーバに飛ぶように、結果計3台のWebサーバをずんび
WS000031

③レッツトライ
秒速で夢破れて山河あり状態。
ばっちりデフォルトに流れています。
WS000025

④説明書どおりにやる
速攻で杜甫状態になったので、pathベースの検証に切り替えます。
http://xx.XXX.com/1a-web →AZが1aのWebサーバへ、http://xx.XXX.com/1c-web →AZが1cのWebサーバへそれぞれ僕の破れた夢を乗せたリクエストが飛ぶはず
※それぞれのWebサーバのDocumentRootには接続時に使用するpathに対応したものを配置しておきます。
WS000027

⑤レッツトライ
Yeah!行きましたね!破れた夢を乗せたリクエストが到達しました!
※接続URLが違うのは、無駄になったWildCard作戦への鎮魂歌です。
WS000028WS000030

結果Pathベースの基本的な挙動についてのみ、
ごく少ない情報量でサラッと触れるという有様になりましたが
どなたかの参考となればうれしい限りです。

こちらからは以上です。







cloudwatchを色々なOSSでモニタリングする

2016.08.11

あれですね、Windows10のanniversary updateで
bash使えるようになったんですね。
bash on ubuntu on windows

あーなんか触ってみたいなと思ったのですが、
うちのマシン、Windows7と8.1からあげてないんですね。
あの何度も何度も「Updateしようよー」って言われてて
もう最後の方は、意地でもあげないもんね、という気分になり
結果上げてないんですね。
でもbash触りたいから、10にしようかと思って調べたら
当然何度も何度も周知されているように有料で、まあ分かっていたけど少しだけ、
少しだけ気持ちが沈みました。
猛アタックされて、なんだか面倒だなと邪険にしてたあの子が
そういえば最近見かけなくなって、どうしんたんだろって思ったら、
彼氏が出来たらしい、と人づてに聞いたときの
「本来味わう権利すらないにもかかわらず、味わう、自分の半径8センチくらいの範囲の喪失感」
の支配下におかれるあの感覚ににてますね。よく分からないですか?僕も分からないです。

さて、AWSのモニタリングに関しては、同じくAWSのサービスとして提供されているCloudwatchがありますね。
OSにログインできるようなサービスであれば、zabbix等の監視サービスを投入することで
割とリッチなメトリクスが簡単に取れますがFullmanagedServiceのモニタリングや
AutoScaling等のサービスとの連携(トリガ)として利用することができることを考えた場合、
(インターフェイスやデータ保持期間は置いておいて)やはりCloudwatch(API)の使い勝手がよいのではないかと思います。
一行で、たくさんのものを置いておくことにしましたが、実際に運用すると、
「おいてきた部分が、やはり、おいてきてはいけなかった部分」だと気づくのも世の常で、
「後ほど検討します」は「まずは安定運用を目指します」になり「ようやく安定したのに、ここでこのような構成変更はリスキーです」に3段活用する季節を何度もすごしてきた
ぼくとしては、やはり何とかしたいと感じるわけです。

で、本題に戻りますと、以下2点をできるだけ、楽に、それっぽく実現したいということなのです。
1.データ保持期限を延ばしたい
2.WebUIをもっとさくっとかこよく見たい

で今回見ていくのは、grafanaです

※以下はイメージです。
WS000000

そうですね、それっぽいですね。
でもgrafanaだけだと、「2.WebUIをもっとさくっとかこよく見たい」
しか実現できない(というか僕が実現する方法を知らない)ので、そこは別ポストで紹介します。

じゃあ作ってみたいとおもいます

1.環境

AMI:Red Hat Enterprise Linux 7.2 (HVM), SSD Volume Type - ami-0dd8f963
OS:Linux 3.10.0-327.el7.x86_64 x86_64 x86_64 GNU/Linux
こんな感じで作りたい:
client -> ELB -> grafana -> cloudwatchAPICall ->nat ->cloudwatch
他:
・subnetはPublic,Privateを準備済み
・NAT、IGWも準備済みでそれぞれのsubnetのDefaultGWになってる
・GrafanaのサーバはPrivateSubnetに立てる
・踏み台にGIPを付けてそこからSSHで入る


2. GrafanaServerの作成

2.1 EC2起動

上記環境で書いたAMIからEC2を起動しますが、その前に
以下のpolicyを保持したでIAMRole(信頼されたエンティティ:ec2.amazonaws.com)
を作っておき、起動時にアタッチします。


{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}


2.2 install
何パターンかありますが、勿論一番楽な以下を選択します
公式のinstall手順を参考に進めて行きます。

sudo yum install https://grafanarel.s3.amazonaws.com/builds/grafana-3.1.1-1470047149.x86_64.rpm -y


ビックリするくらい、何事もなくインストールが完了します。

2.3 起動と自動起動の設定

Install時にinitScriptも一緒に配置されていそうですが
個人的に未だにsystemdに苦手意識があるため、systemdの方で操作します。


sudo systemctl daemon-reload
sudo systemctl start grafana-server
sudo systemctl enable grafana-server.service
sudo systemctl status grafana-server


3.ELBからつなげる

3.1 Grafanaは待ち受けているか
grafanaはdefaultがport:3000でListenするらしく
netstatで確認すると確かに待ち受けてる


$ netstat -an | grep 3000
tcp6 0 0 :::3000 :::* LISTEN
$


conf(/etc/grafana/grafana.ini)も触りたいところだけど
動くところを見ないと、テンションが続かないので
まずは全体の通信を通してしまいます

3.2 ELBを作ろう
ELBはPublicSubnetに立てて、tcp80(HTTPだとプロトコルレイヤが違って怒られます)で待ちうけ、
裏に居るGrafanaのTCP3000に対してリクエストを投げます。
なんと言葉だけで説明を終了しようとしています。

3.3 つなげてみる

ELB(External)を作るとEndpoint用のDNSレコードが払い出されるので
配下のインスタンスが「Active」になったら早速つなげてみます

WS000002

はい来た!

初期IDとPassはいずれもadminです。
Password変更は以下のようにGlobalUsersの所から行えます。

WS000003

editを選んで、passwordをupdate。

WS000004

4. Grafanaのデータソースを設定する

Grafanaがモニタリング状況の描画に利用するデータソースを定義します。
データソースは以下の部分で行いますが、

WS000006


WS000007


以下のような形で設定します。

Name=データソースを識別する名前です。好きなものを付けましょう
type=cloudwatch
credentialprofilename=なし ※1
Default Region=ap-northeast-1
Custom Metrics NameSpace=なし ※2
Assume Role ARN=なし※3


※1
grafanaサーバ上にあるAWSのクレデンシャルファイルの「プロファイル名※ここ大事」を指定します。クレデンシャルファイルはgrafanaServerサービスを起動しているユーザ[grafana]のhomeに配置する必要があります。
今回の手順だと/usr/share/grafanaがgrafanaのhomeになるので、そこに.awsディレクトリを作成し、credencialsというファイル名でファイルを作成しaccessKey,secretKeyを記載します。
今回、定義なしなのは、EC2にあらかじめIAMロールを付与しておいたから、そちらの権限でまかなえている印象です。

※2
カスタムメトリクスを取得した場合はここで名前空間(AWS/EC2のような形式)の定義が必要なようです(未検証)

※3
サラッとしていますが、サーバ上のAWSクレデンシャルファイルを参照するパターンは以前若干苦戦して設定しております。
またIAMのロールをサードパーティーから利用できるようにするには、なんだかドキュメントから上手くID周りを見つけられませんでした。
なので結果的にEC2にIAMRoleを付けている、という状態になっています。


では、グラフを作成しましょう。
左上のGrafanaマークからDashBoardを選択し、Newぽいのを選びます
若干操作に慣れが必要なのですが、以下のような形で、
Panel Data Source=cloudwatchにして、描画したいメトリックを選択していきます。

WS000012

以下は、Grafanaへの通信を待ち受けてるELBのメトリクスを描画したものです。(ELBはTCPで作ってしまっているので、HTTP周りのメトリクスがとれないので、かなり寂しい感じですが)

WS000013

こんな感じで、どんどん描画対象のメトリクスを追加して行きます。

WS000014


センスの無さに震えが止まりませんが、今日はここまでにします。
次回は「データ保持期間を延命させるには?」について書いて見たいと思います。

こちらからはいじょうです。