AWS X-RayでLambda→Athenaのアクセスを可視化してみた

以前こんなものを作りましたが、これをAWS X-Rayで可視化してみたら、何がわかるのか、実験してみました。

Amazon AthenaをAWS Lambdaから操作できるようにしてみた

AWS X-Ray デーモンの実行

AWS X-Ray SDK は、AWS X-Ray に Trace データを直接送信しないらしいので、送付用のEC2インスタンスを作成します。ユーザデータとして以下を登録してインスタンスを生成するだけなので、簡単です。

#!/bin/bash
curl https://s3.dualstack.us-east-1.amazonaws.com/aws-xray-assets.us-east-1/xray-daemon/aws-xray-daemon-2.x.rpm -o /home/ec2-user/xray.rpm
yum install -y /home/ec2-user/xray.rpm

システムログにxrayのインストールログが出力されていたのでOKでしょう。

Examining /home/ec2-user/xray.rpm: xray-2.0.0-1.x86_64
Marking /home/ec2-user/xray.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package xray.x86_64 0:2.0.0-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package         Arch              Version               Repository        Size
================================================================================
Installing:
 xray            x86_64            2.0.0-1               /xray            6.6 M

Transaction Summary
================================================================================
Install  1 Package

Total size: 6.6 M
Installed size: 6.6 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : xray-2.0.0-1.x86_64                                          1/1 
xray start/running, process 2576
  Verifying  : xray-2.0.0-1.x86_64                                          1/1 

Installed:
  xray.x86_64 0:2.0.0-1                                                         

Complete!

Lambdaアプリ側の準備

今回Javaアプリケーションを動かすわけですが、LambdaアプリケーションをX-Rayで監視したい場合は、Lambdaアプリケーションの「設定」タブの中で以下のチェックボックスをONにするだけで良いようです。

スクリーンショット 2017-04-23 22.21.44.png

参考:http://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-services.html

またX-Rayを操作するための権限をIAMで設定する必要もあります。今回は試験的な運用だったため「AWSXrayFullAccess」をつけてしまいましたが、実際の運用に合わせてこの辺りは慎重に選びたいですね。

アプリを起動して可視化してみる

ここまでできれば、普通にLambdaアプリを動かしてみてX-Rayでどのように見えるのか確認ができます。今回Lambdaアプリケーションには以下のJSONをインプットとして与えるようにしました。以前の記事でサンプルとしてAthenaのテーブルからデータを取得するようにした際の入力値です。

{
  "region": "us-east-1",
  "s3Path": "s3://ishida-athena-staging-dir/",
  "sql": "SELECT elbname, requestip,  requestport, backendip, backendport, requestprocessingtime, backendprocessingtime, timestamp FROM sampledb.elb_logs order by timestamp desc limit 10",
  "columnListStr": "elbname, requestip,  requestport, backendip, backendport, requestprocessingtime, backendprocessingtime,  timestamp"
}

実行後1分ほど待つと、以下のような表示がX-Rayで確認できました。無事可視化ができたようです。

スクリーンショット 2017-04-23 22.56.40.png

X-Rayの中身を確認してみる

表示されたService Mapの右側のオブジェクトをクリックすると以下のような表示がされました。
スクリーンショット 2017-04-23 22.56.51.png

それぞれの処理にどの程度時間がかかってレスポンスとして何を返しているのかが一覧でわかります。
表示されているIDをクリックすると、そのTraceの詳細が確認できました。

スクリーンショット 2017-04-23 22.56.58.png

これをみる限り、Lambdaアプリの初期化に230ms程度、実際のAthena接続部分に約3秒程度かかっている、という風にみればいいんですかね。この処理全体としては4.6秒かかっているので、実際にAthenaにアクセスするため以外に1.5秒ほどは時間が取られている、と理解すればいいんでしょうか。この辺はもっと勉強が必要だ(^^;

ちなみにエラーが出ている場合は、その例外の中身も確認することができるようです。

まとめ

それぞれの処理がどの程度時間にかかっていて、さらに呼び出し関係までこれほど簡単にセットアップしつつ可視化ができるのは強力ですね。これからMicroservicesなどで分散して処理をさせることが当たり前になることを考えると、必須の技術と言えると思います。Springで言えばZipkinとSleuthをAWS上で実現しているような感じですね。

続きを読む

Terraformでstate lockを触ってみた。

はじめに

初めてTerraformを触る折に
「v0.9以上だとstate lockっていう機能があるから使ったほうが良いよ」
というアドバイスをもらいました。
(そもそも、stateってなんですか?から始まるわけですが・・・)

初めてTerraformを触った時に、公式ドキュメントだけでは???な状態だったので
痕跡として残しておきます。

結果として、まだ使いこなせてません。というか僕の使い方は果たしてあっているのだろうか
なので情報としては不足しているかもしれませんが、とりあえず備忘録的に残します。
またわかったらUpdateします。

そもそもState Lockとは

完全に理解しないで書いてますが
Terraformは「自分が知っているリソース(EC2やS3)しか関与しないよ」というポリシーで
どのリソースを自分が扱ったか、というのをtfstateというJSONファイルで管理しているようです。

このtfstateファイルは、一人でTerraformを動かす場合は問題無いのですが
複数人でTerraformをいじる必要が出てきた時に問題で、それは「backend」モジュールを使うことで回避してきたようですが
同じタイミングでterraformを実施した場合、その部分までは制御しきれてなかったようです。

で、v0.9以上?から、「Plan/Applyをしているタイミングではロックする」機能が実装されたようで。
せっかくなので導入してみました。

公式サイト:https://www.terraform.io/docs/state/locking.html

準備

手動で準備が必要なものは
・terraformを実行するユーザのCredential情報
→ めんどくさかったので test-terraformとかいうユーザを別途作成しました。
・S3 Bucketの作成
→ terraform-s3-state とかいう名前で作りましょう
・DynamoDBの作成
→ 名前はなんでも良いです。terraform-state-lock とかで作りましょう。
  プライマリキーを「LockID」としてください。それ以外では動きません。
作り終えたら、読み込み・書き込み容量ユニットは最低の1にしておいたほうが良いと思います。

※ S3とDynamoDBをterraformで管理はしないほうが良さげです。
どのみち、初回実行時に「そんなリソース無いんだけど!」ってTerraformが怒ります。

動くまで

今回はState Lockの話がメインなので作るリソースはなんでも良いです。
リージョンが関係無いRoute53を題材にします。

route53.tf
# 適当に1ゾーン作ります。

resource "aws_route53_zone" "test_zone" {
    name    =   "test.lockstate.com"
}
settings.tf
# ネーミングよくないですが、providerとbackendの設定します

provider "aws" {
    access_key = "ACCESS_KEY"
    private_key = "PRIVATE_KEY"
}

terraform {
    backend "s3" {
        bucket     = "terraform-s3-state"
        key        = "terraform.tfstate"
        region     = "s3とdynamoがいるregion"
        lock_table = "terraform-state-lock"
    }
}

これで、「該当のディレクトリに移動して」$ terraform plan してください。(怒られます。)

Backend reinitialization required. Please run "terraform init".
Reason: Initial configuration of the requested backend "s3"

The "backend" is the interface that Terraform uses to store state,
perform operations, etc. If this message is showing up, it means that the
Terraform configuration you're using is using a custom configuration for
the Terraform backend.

とりあえず terraform init しろよと言われるので言われるがままに。

$ terraform init

ただし、以下の通り、認証情報がねーんだけど!って怒られる。なんやねん。

Initializing the backend...

Error configuring the backend "s3": No valid credential sources found for AWS Provider.
  Please see https://terraform.io/docs/providers/aws/index.html for more information on
  providing credentials for the AWS Provider

Please update the configuration in your Terraform files to fix this error
then run this command again.

ここらへんちゃんとよくわかってないですが、この問題の対処として2つありました。
A. settings.tfのbackendにaccess_key/secret_keyの2つを渡してCredential情報を平文で書く。
-> 変数でいいじゃん!と思ったんですが、変数で渡すと、Terraformがよしなにやる「前に」
  Backendが立ち上がるために違う方法で渡してくれ、と怒られました。
以下のようなメッセージ

% terraform init 
Initializing the backend...
Error loading backend config: 1 error(s) occurred:

* terraform.backend: configuration cannot contain interpolations

The backend configuration is loaded by Terraform extremely early, before
the core of Terraform can be initialized. This is necessary because the backend
dictates the behavior of that core. The core is what handles interpolation
processing. Because of this, interpolations cannot be used in backend
configuration.

If you'd like to parameterize backend configuration, we recommend using
partial configuration with the "-backend-config" flag to "terraform init".

B. 環境変数にaccess_key/secret_keyの2つを食わせる
  → 今はこちらを採用中。

init or plan実行時に、状況に応じて「ローカルのStateをS3にコピーするか / S3からStateファイルをローカルにコピーするか」聞かれるかもしれません。
初回(もしくはテスト)であればYes、すでに何回か実行しているような状況ではnoでいいんじゃないでしょうか。

これで、terraform plan (or apply)を実行すると
DynamoDBのLockDBに対して誰が使用しているか、のロック情報が書き込まれ
終わったタイミングでリリースされます。

ターミナルやシェルを複数立ち上げ、同じぐらいのタイミングで
terraform plan( or apply )を実行すると、ロックが成功できた奴以外はエラーで落とされます。
ただし、ロックがリリースされる前の実行中などにCtrl-Cなどで強制終了させるとロックが残り続けるので注意。
$ terraform force-unlock ID情報
で強制ロック解除できます。

今僕が解決できてない問題点

公式ドキュメントを見る限り、「terraform remote コマンドは terraform initコマンドに置き換えたよ!」と言っています。
また、backendを使用する、backendを書き換えた、などのタイミングに起因して terraform init を求められます。

が、terraform initは、「実行されたディレクトリに対して .terraform/terraform.tfstate」を吐き出します。
そしてそれが無いと怒ります。
まだ試せてはいませんが、以下のようなtfの配置をしていたりした場合
root配下でinitを実行しても、tfファイルがありませんと怒られる状況で
tfファイルがあるディレクトリまで移動しないとinitができない状態です。

$ terraform init ./route53/tf
とするとroot直下にtfファイルがコピーされる状況です。
なので、リソースごとに区切る、とか環境ごとに区切る、とかはうまくできていません。
別の見方をすれば、環境ごとに一つのディレクトリでリソース類は全部その中で管理しろよ!
というHashiCorpからのお達しなのか・・・?
これは、新しく実装されたEnvironmentを試せ、ということなんでしょうか。。。

と思ったらBackendConfigなるものがあるらしいのでそれを試してみよう。

root
├── settings
│   └── tf
│   └── settings.tf
├── route53
│   └── tf
│   └── route53.tf
└── ec2
└── tf
└── ec2.tf

Terraformとの付き合い方がよくわからない

続きを読む

Amazon EC2上のRed Hat Enterprise Linuxにリモートデスクトップ接続してElixir ReportをGUIインストールする手順

クラウド環境のLinuxインスタンスに、帳票ツールのElixir Reportをインストールする手順をまとめています。

参考までに、以前の記事はこちら。
Amazon EC2上にRed Hatインスタンスを作成してElixir Reportをコンソールインストールする手順
Amazon EC2上のRed Hat Enterprise LinuxにX11転送でElixir ReportをGUIインストールする手順

今回は、Amazon EC2上のRed Hatインスタンスに、デスクトップ環境VNCサーバーをインストールして、WindowsからVNCクライアントを使って接続し、Elixir ReportのレポートサーバーをGUIインストールする手順を試してみたいと思います。

環境

Windows 8.1
Elixir Report 8.7J
UltraVNC 1_2_12 64bit
Amazon EC2 Red hat Enterprise Linux 7.3
tigervnc-server

Red Hatインスタンスを作成して、パスワード認証を許可する

  1. Amazon EC2上に、デフォルトの構成でRed Hatインスタンスを作成します。以前まとめた、Amazon EC2上にRed Hatインスタンスを作成してElixir Reportをコンソールインストールする手順[Red Hatインスタンスの作成と準備]を参考にしてください。

    セキュリティ設定のポートの開放では、レポートサーバーが使用するポート7001と、サンプルのTomcatで使用するポート9090だけでなく、VNCが使用するポート5901も追加する必要があるので、注意してください。

  2. Windowsから作成したインスタンスにSSH接続します。この記事ではTera Termを使用します。Tera Termのインストール手順については、こちらも以前の記事[SSH接続用にWindowsにTera Termをインストールする]を参考にしてください。

  3. Tera Termでインスタンスに接続したら、パスワード認証(PasswordAuthentication)を許可するように変更します。sshd_configは念のためバックアップを取っておいてください。変更後のsshd_configは次のようになります。

    $ cat /etc/ssh/sshd_config|grep Pass
    PasswordAuthentication yes
    #PermitEmptyPasswords no
    #PasswordAuthentication no
    #KerberosOrLocalPasswd yes
    
  4. sshdサービスを再起動します。

    $ sudo systemctl restart sshd.service
    
  5. ec2-userのパスワードを設定します。

    $ sudo –i
    $ passwd ec2-user
    パスワード入力
    
  6. Tera Termを新しく起動して、パスワードでログインできるか試してみます。

Red Hatに、デスクトップ環境とVNCサーバーをインストールする

  1. Tera TermでRed Hatインスタンスに接続して、パッケージのグループServer with GUIをインストールします。

    $ sudo yum grouplist
    $ sudo yum -y groupinstall 'Server with GUI'
    
  2. 次にVNCサーバーをインストールします。

    $ sudo yum –y install tigervnc-server
    
  3. VNCサーバーのパスワードを設定します。

    $ vncpasswd
    Password:
    Verify:
    
  4. VNCサーバーのユニットファイルをコピーします。

    cp -a /lib/systemd/system/vncserver@.service /etc/systemd/system /vncserver@:1.service
    
  5. コピーしたユニットファイルを編集して、<USER>の部分をログインユーザー名ec2-userで置き換えます。

    $ vi /etc/systemd/system/vncserver@:1.service
    ExecStart=/usr/sbin/runuser -l ec2-user -c "/usr/bin/vncserver %i"
    PIDFile=/home/ec2-user/.vnc/%H%i.pid
    
  6. ファイアウォールの設定にVNCサーバーを追加します。また、レポートサーバーが使用するポート7001も許可しておきます。

    $ firewall-cmd --permanent --zone=public --add-service=vnc-server
    $ firewall-cmd --zone=public --add-port=7001/tcp --permanent
    $ firewall-cmd --reload
    $ firewall-cmd --list-all
    
  7. rootでVNCのサービスを起動します。

    $ sudo su –
    # systemctl start vncserver@:1
    
  8. Windowsに、VNCクライアントとしてUltraVNCをインストールします。筆者は以下のサイトからダウンロードしてインストールしました。

    窓の杜 UltraVNCUltraVNC_1_2_12_X64_Setup.exe

  9. UltraVNC Viewer を起動して、VNC Serverの入力箇所にRed HatインスタンスのIP::ポート(またはIP:ポート)と入力して、Red Hatインスタンスのデスクトップに接続できることを確認します。
    1vnc接続成功.png
    接続できました。

Red HatへVNC接続してレポートサーバーのインストーラを実行する

  1. UltraVNC ViewerでRed Hatインスタンスに接続します。

  2. レポートサーバーのインストーラをTera TermからSCPで転送し、実行権限の設定を行います。この手順の詳細は、以前の記事、Amazon EC2上にRed Hatインスタンスを作成してElixir Reportをコンソールインストールする手順[レポートサーバーのインストーラをRed Hatに転送する]を参照してください。

  3. Tera TermまたはRed Hatインスタンスのコンソールを開き、必要なライブラリをインストールします。このライブラリインストールはコマンドインストール、X11転送でのGUIインストールでも行います。

    $ sudo yum -y install libc.so.6
    
  4. レポートサーバーのインストーラを次のコマンドで起動します。

    $ ./elixirreport87_linux64.bin
    

    2VNC_GUIインストーラ00.png

  5. その後の手順の詳細は、以前の記事、Amazon EC2上のRed Hat Enterprise LinuxにX11転送でレポートサーバーをGUIインストールする手順[GUIインストールを実行する]を参考に完了させてください。

インストールしたレポートサーバーを起動する

  1. レポートサーバーを起動するユーザーのLANG環境変数を日本語ロケールへ変更します。

    $ export LANG=ja_JP.UTF-8
    
  2. レポートサーバーをインストールしたディレクトリ以下の/binに移動します。筆者の環境では、/home/ec2-user/ElixirReport87J/bin/になります。

    $ cd /home/ec2-user/ElixirReport87J/bin
    
  3. レポートサーバーの起動シェルスクリプトを実行します。

    $ ./reportserver-start.sh
    

    ※”&”を付加することでバックグラウンド実行にします。

  4. 起動に成功すると、コンソール上に次のようにCopyrightが表示されます。

    INFO  [main] com.elixirtech.ers2.Main - Copyright 2016 Elixir Technology Pte Ltd
    INFO  [Thread-19] com.elixirtech.ers2.EnsureServerStarted - Checking server status
    
  5. Windows上のブラウザからレポートサーバーのWebインターフェースにログインしてみます。

    http://<パブリックIP>:7001
    

    3WebインターフェースURL.png

    【注意】ログイン画面が表示されないときは、以下のような原因が考えられます。
    ・レポートサーバーの起動に失敗している
    ・Red Hatインスタンスのセキュリティグループの設定で、ポート7001を追加していない
    ・Red Hatインスタンスのファイアウォール設定でポート7001を許可していない

  6. ログイン画面が表示されたら、デフォルトで用意されている次の管理者ユーザーでログインします。

    ユーザー名: admin
    パスワード: sa
    
  7. [リポジトリ]以下のサンプルテンプレートを実行してみます。[samples]‐[demo]-[sales2]-[sales2.rml]を選択して、出力形式に”PDF”を選んで[OK]をクリックすると、レポートが生成されます。
    4ロケールを日本語にして、PDFもできます.png

以上で完了です。

続きを読む

EC2-ローカル間でのファイル転送

3行で分かるあらすじ

  1. EC2内でエクスポートしたsqlファイルをローカルに転送させたかった。
  2. FileZillaでSFTPを使って転送しようとしたが、なぜかsqlファイルが表示されなかった。
  3. 表示されない原因調べるのも馬鹿らしいのでscpで転送した。

環境

ローカル:Mac
Amazon EC2:Amazon Linux

EC2 → ローカル 転送

scp -i [公開鍵ファイルのパス] [ユーザ名@ドメイン]:[送信元EC2ファイルパス] [転送先ローカルファイルパス]

#scp -i /keys/hoge.pem user@ec2-xxxx.com:/sqls/hoge.sql /Desktop

ローカル → EC2 転送

scp -i [公開鍵ファイルのパス] [送信元先ローカルファイルパス] [ユーザ名@ドメイン]:[転送先EC2ファイルパス]

#scp -i /keys/hoge.pem /Desktop/hoge.sql user@ec2-xxxx.com:/sqls

まとめ

エンジニアたるものGUIばかりに頼っていてはいけないな!な!(戒め)

続きを読む

AWSにDjango環境を構築する

versions

Python : 2.7
Django : 1.10

Environment

EC2インスタンス : Amazon Linux
WSGI : gunicorn
Proxy : nginx

install python packages

sudo yum update
sudo yum install gcc
sudo yum install python-devel
sudo yum install python-psycopg2
sudo yum install postgresql-devel
pip install -r requirements.txt

reverse proxy

sudo yum install nginx
sudo vi /etc/nginx/nginx.conf
  • nginx.confに追記 line : 49
location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

# http://mydomain/static/ をDjangoのsettings.pyでSTATIC_ROOTに指定したディレクトリへルーティング
location /static/ {
    autoindex on;
    alias   /usr/share/nginx/html/django-project-name/staticfiles/;
}
sudo chmod 777 -R /usr/share/nginx/html ※1
sudo service nginx restart
gunicorn django-project-name.wsgi -D

Memo

python manage.py runserver 0.0.0.0:8000  # 全てのホストアドレスからのアクセスを許可
python manage.py migrate
python manage.py createsuperuser

# 事前にsettings.pyにSTATIC_ROOTを設定する (defaultでは記載されていない)
python manage.py collectstatic  # STATIC_ROOTに指定したディレクトリに静的ファイルが生成される

※1 : このディレクトリ下にDjangoプロジェクトを設置
当初はSTATIC_ROOTに設定したディレクトリのシンボリックリンクのみをここに貼ったが
静的ファイルを読み込む際に403エラーが発生してしまうためプロジェクトごとこのディレクトリに設置
所有がrootのディレクトリに対して、パーミッションを777に設定してしまうのは多少疑問が残るところ

SSL証明書

証明書はAWS Certificate Managerで発行し、Elastic Load Balancerにインストール
ELBとEC2間の通信はhttpとなるが、ELBとEC2が同じリージョンにある場合セキュリティの問題はなさそう

続きを読む

EC2のEBSボリュームをresize2fsせずに拡張する

概要

EC2のEBSボリュームを拡張する(10G -> 90G)
EC2はすでに起動済みのものとする。

背景

EBSのボリュームを拡張したので、ファイルシステム拡張のコマンドを実行!

$ sudo resize2fs /dev/xvda1
The filesystem is already 8972864 blocks long.  Nothing to do!

パーティションの容量が少ないためディスクの拡張ができず、怒られてしまいました・・・。
Linux パーティションの拡張が必要そうですが、ちょっと手順が多い。

しかし、サイズをEBSのサイズをあらかじめ拡張し、スナップショットから新規作成することで
コマンドを実行せずともwebコンソールからディスクを拡張できたので手順をメモ。

事前準備

  • EC2で使用してるEBSのID、ルートデバイスの名前を控える。

スクリーンショット 2017-04-19 20.14.28.png

  • EC2のインスタンスID、アベイラビリティーゾーンを控える。

手順

EBSボリュームサイズを拡張する

※EC2を停止しなくても拡張できますが、拡張中は不安定になります。

ELASTIC BLOCK STORE > ボリューム > アクション > Modify Volume
Sizeの値を変更します。

スクリーンショット 2017-04-19 21.38.05.png

EBSボリュームのスナップショットを作成する

※EC2を停止しなくてもスナップショットを作成できますが、停止したほうが安全です。

ELASTIC BLOCK STORE > ボリューム > アクション > スナップショットの作成

EC2を停止する

以降の作業はEC2を停止しないと行えません。

EBSボリュームをEC2からデタッチする

ELASTIC BLOCK STORE > ボリューム > アクション > ボリュームのデタッチ

既存のEBSをデタッチします。

EBSボリュームのスナップショットから新しいボリュームを作成する

ELASTIC BLOCK STORE > スナップショット > アクション > ボリュームの作成

EC2と同じアベイラビリティゾーンにする必要があります。

スクリーンショット 2017-04-19 20.11.33.png

新規作成したEBSボリュームをEC2にアタッチ

ELASTIC BLOCK STORE > ボリューム > アクション > ボリュームのアタッチ

アタッチしたいEC2のインスタンスを選択します。
事前に控えておいたデバイスを入力します。

スクリーンショット 2017-04-19 20.24.48.png

EC2を起動

これで作業完了です!

ディスクボリュームが拡張されているか確認する

$ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  90G  0 disk
└─xvda1 202:1    0  90G  0 part /

$ df -h
ファイルシス       サイズ  使用  残り 使用% マウント位置
/dev/xvda1            89G   84G   5G   18% /

最後に

使用していないEBSは削除しましょう!
EC2にアタッチしていなくても、料金がかかってしまいます。

続きを読む