ヤマ

こんにちは、

 

先日、リビングに敷くためのラグを

パルコの雑貨屋さんで購入しました。

 

インドでの手作りラグは、機械で作るのとは違い

見た目も決して綺麗に整っているわけではないですが、

シンプルで手作り感もあり、気に入っています。

 

で、リビングに置いたわけですよ。

 

ルンバさんの居る、リビングにね。

 

 

対する、ラグは、

http://honda-kagu.net/shop/item/honda/picture/goods/10222_1_expand.jpg

 

こんなイメージのもので、

四隅に、ヒラヒラがついているわけですよ。。。。

 

 

完全に、忘れてましたね。

ルンバさんのことを。

 

で、戦いの結果は、

 

ルンバ:(#`皿´)

ラグ:(_TдT)

 

こんな感じでした、、、ヤマです。

 

 

 

本題

 

 

ELB(AWSサービスの一つ、バランサ)

を一つ構えて、配下にEC2インスタンスを2台設置しました。

 

設置当初は、何も考えて無かったのですが、

ログの扱いをすっかり忘れていたことに、気づきました。

 

ログと言っても、WEBサーバのアクセスログではなく、

アプリから吐き出すログです。

 

セッションはDBに持っており、

どちらのサーバに振られてもいい様になっています。

 

この状況で、以下の解決方法を試してみました。

 

1)ログ出力先をS3にする

 サーバ1もサーバ2も、ログの出力先を同じS3バケットにすることで解決しようとしました。

 施策としては非常に簡単です。

 EC2からS3の特定バケットをマウントするだけ。

 

 結果

  S3へのアクセスが遅すぎて使えない

  実用に耐えられないほどの遅さでしたので、断念。。。

 

 

2)Cloudwatch Logsを利用する

 CloudWatch LogsのAgentをインストールして、定期的にログをCloudWatch Logsへ上げる。

 最初から素直に、この方法にしておけばよかったです。

 

 一つ懸念としては、複数EC2インスタンスから、同じロググループ、ログストリームに

 アップした事がなかったので、実現できるか心配だったこと。

 

 結果

  ほぼリアルタイムで閲覧でき、大満足

 

  各種ログをほぼリアルタイムで同期でき、サーバへアクセスすることなく、

  CloudWatch Logsコンソール上でログを閲覧できるので、かなり役立っています。

 

 

手順を簡単に書いておきます。

前回書いた記事も参考に。「CloudWatch Logs

 

 

1)IAM Roleを設定

 

CloudWatch Logsへのアクセス権限を持つIAM Policyを作り、

それを特定のIAM Roleに割り当てます。

で、そのIAM RoleをEC2インスタンスに割り当てます。

 

2)スクリプト入手&実行

https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py

 

実行権限を与えて、pythonで実行してください。

python ./awslogs-agent-setup.py –region ap-northeast-1

 

 

3)設定ファイル編集

/var/awslogs/etc/awslogs.conf

を良い感じに編集してください。

 

 

この設定を、2つのサーバ(EC2インスタンス上)で設定して、

それぞれのサーバのログを、CloudWatch Logsで収集するようにしました。

 

 

ヤマ

こんにちは、

「決戦は金曜日」、、、ではなく、

「日曜日はプレゼン」な、ヤマです。

 

タイトル通り、

 

AWSの「API Gateway」と「Lambda」を使って、社内専用の「slack bot」を

作ってみたいと思ってます。

 

サーバレスで。

 

 

すべての手順を書くと、ものすごく面倒なので、いつものように概要だけ。

 

ハショリマス。

slackは既にアカウントをお持ちという前提で。

 

処理の全体は以下のようになります。

 

slackへ投稿 ⇒ Outgoing Webhook(slack) ⇒ API Gateway(AWS) ⇒ Lambda(AWS) ⇒ Incoming Webhook(slack) ⇒ ボットからの返答が表示される

 

 

以下、作成手順

 

1)Outgoing Webhook を登録します

 Outgoing Webhookには、ボットを呼び出すキーワードを「Trigger Words」に設定します。

 API Gatewayを呼び出すためのURLを指定します。(後から作るAPI GatewayのエンドポイントURLを指定してください)

 

2)Incoming Webhook を登録します

 Incoming Webhookでは、Lambda(AWS)から投稿するためのURLが生成されますので、

 作って控えておきましょう。

 

3)Lambdaを作成します

 node.jsを触った事がないので、ここは下記の記事を参考にさせて頂きました。

 http://qiita.com/tmtysk/items/7161b11e20ac5e2dfc01

 投稿先は、slackのIncomingWebhookで生成されたURLです。

 

 

4)API Gatewayを登録します

 「APIを作成」から作成します。

 POSTメソッドを作成し、「メソッドリクエスト」内の「URLクエリ文字列パラメータ」に、

 OutgoingWebhookで渡されるパラメータ群を設定します。

 詳しくは、OutgoingWebhook画面内にある「Outgoing Payload and Responses」をexpandすると

 表示されますので、そちらをご覧ください。

 

 続いて、「統合リクエスト」内にある、本文テンプレートマッピングを編集します。

 slackからPOSTされる「x-www-form-urlencoded」を、Lambdaで処理する「JSON」へマッピングするための処理です。

 こちらの記事が参考になりそうです。

 http://tech.feedforce.jp/aws-lambda.html

 

 最後に、デプロイしてエンドポイントURLが生成されますので、OutgoingWebhookのURLで指定します。

 

 

えらいハショッテしまいました。。。(・ω・;)

 

 

slackに対して、特定の文字列を投稿すると、OutgoingWebhook(slack)が反応して、APIGateway(AWS)を呼び出し、

APIGateway(AWS)はOutgoingWebhook(slack)でPOSTされるデータをうまいこと、JSONに変換して、Lambda(AWS)へ渡します。

Lambda(AWS)でデータを受け取り、好きなように処理したあと、

IncomingWebhook(slack)に対して投稿すれば、ボットからslackへ自動的に投稿される、

という仕組みです。

 

Lambdaの裏では、node.jsが動いています。

Java8やPythonも動きますので、

完全にサーバレスなWEBアプリが作れちゃいます。

もちろんさらにその裏ではDBサービスとの連携もできます(たぶん。。。)

 

Lambdaでは、リクエスト回数と、実行時間、処理に割り当てるメモリによって

料金が変わるようです。

 

わざわざサーバを立てず、お手軽に連携アプリを作るなら、

選択肢の一つとしていかがでしょうか。

 

ちなみに今回は、AWSの色んなサービスを使ってみようと思い、

勉強も兼ねて作っています。

間違いなどありましたら、ぜひご指摘ください!

 

【カテゴリ】Webサイト
【タグ】
ヤマ

こんにちは、ヤマです。

ずっと気になっていた「AWS」、
仕事で調べる機会があり、ここ数日試行錯誤しながら環境を構築しました。

いまさら感がありますが、備忘録も兼ねて。

AWSはクラウド環境が超簡単に作れる上に、
公開されているAPIを組み合わせることで、超速で構築が可能です。

Private+Public環境に関しては、AWSのVPCメニューから
そのものずばりのメニューがあり、ほぼボタン1発で構築が可能です。
今回はVPCを理解するためにも、全て手動で構築することにしました。

PrivateサブネットとPublicサブネットの環境とは、
例えば公開用WEBサーバの後ろに、Privateな環境でDBサーバがある、などです。

VPCを作る

VPC → 「Create VPC」 を選択し新しいVPCを作ります。
VPCのネットワークのレンジは構築後は変更できません、「CIDR block:」は慎重に指定しましょう。
今回は「192.168.0.0/16」としました。

サブネットを作る

Public用とPrivate用のサブネットをそれぞれ作ります。
同じく、VPC → 「Subnets」 → 「Create Subnet」を選択して作ります。
「VPC」欄からは先ほど作ったVPCを選択します、

CIDRには、
Public用:192.168.0.0/24
Private用:192.168.1.0/24
を指定しました。

ゲートウェイを作る

「Internet Gateway」 → 「Create Internet Gateway」でゲートウェイを作ります。
作ったら先ほどのVPCにAttachします。

ルーティングテーブルを作る

VPCを作ると、デフォルトのルーティングテーブルが作られています。
今回はそれとは別に、Public用のテーブルを作りました。
「Route Tables」 → 「Create Route Table」を選択して作ります。

同様に、VPCには先ほどのVPCを選択して作ります。
作ったら「Route」タブにて実際のルーティングを指定します。
Public用なので、
Destination:0.0.0.0/0
を指定、
さらにTargetには、先ほど作ったゲートウェイを指定します。

また、「Subnet Associations」で、
Public用のサブネットに関連づけします。

これで9割方完成

実は、、、、ここまで来るのに試行錯誤しました。
ですが、一度出来るようになれば簡単です。
この工程を全て自動化もできるのでしょうか?今後チャレンジしてみます。

ここまでの工程で、作りたいVPCの9割方が完成していますので、
あとは、

  1. インスタンスを作る際に、ここで作ったVPCを選択し、どのサブネットに入れるかを決める
  2. PublicサブネットとPrivateサブネット間の通信(SSHとか)は、SecurityGroup、NetworkACLsで適切にポートと宛先を指定する、

などの工程に注意しながら進めればOK

実は2つ目で結構ハマリました。(汗

今後も新しい事が出来るようになりましたら、
少しずつ公開していこうと思います。

それでは、楽しいAWSライフを

【カテゴリ】Webサイト
【タグ】

プロフィール

愛知県名古屋市にあるジャスウィルで働く社員です。

ジャスウィルは大学事業に特化したシステムを提案しています。『大学向け事務・教務統合パッケージ―TriR Campus』を開発しています。


Facebookページでは、イベントや普段の社員の様子を公開中♪
ぜひご覧ください☆

過去一年の月別記事 全て表示