Setup AWS server with SSL + other related setting

さらに表示: aws server setup, setup email server aws, aws setup smtp server, smtp server setup aws, setup proxy server aws, aws setup mail server, setup web server amazon aws, setup aws server, setup php server verification email, webmin setup sendmail server, dedicated server ssl installation, … 続きを読む

AWS AppSyncとReactでToDoアプリを作ってみよう(3) Reactアプリの作成

はじめに

前回の記事まででは、AWS AppSyncを使ってGraphQL APIを作成しました。
今回は、そのGraphQL APIと連携するクライアント側Reactで作成してきたいと思います。
AWS AppSyncでは、React向けのGraphQLクライアントのApolloに対応した、aws-appsync-react (バインディングライブラリ)が用意されているので、今回はこれを使って、AWS AppSyncのデータとコンポーネントの紐付けを行っていきます。

プロジェクトのセットアップ

雛形の作成

Create React Appを使って、雛形を作成します。
(今回使用したnodeのバージョンは9.2.0です。)

$ mkdir aws-appsync-todo-app
$ npx create-react-app .

追加で必要なパッケージをインストールします。

$ yarn add graphql-tag react-apollo aws-appsync aws-appsync-react uuid
  • graphql-tag

    • GraphQLのスキーマをJavaScriptのコード内に定義するために使用
  • react-apollo
    • GraphQLクライアント
  • aws-*のパッケージ
    • AWS AppSyncとApolloを連携するために使用
  • uuid
    • Todo個々のアイテムにクライアント側でユニークなIDをつけるために使用

設定ファイルの取得とインポート

コンソール画面から、「AWS AppSync > 作成したプロジェクト > Top画面」を開き、「Getting Started」の一番下にある、「Download the AWS AppSync.js config file」からAppSync.jsをダウンロードします。

スクリーンショット 2018-01-25 22.17.20.png

ダウンロードしたファイルを、作成したプロジェクトのsrc以下に配置し、他のパッケージと合わせてApp.jsにインポート

App.js
import { ApolloProvider } from 'react-apollo';
import AWSAppSyncClient from "aws-appsync";
import { Rehydrated } from "aws-appsync-react";
import appSyncConfig from "./AppSync";

AppSyncClientを初期化

設定ファイルから読み込んだ、AWS認証情報・API情報を引数に、AWS AppSyncClientを初期化します。
authパラメータで認証方式を選択できますが、今回はAPI Keyによる認証を使用します。

App.js
// AWS AppSync Client
const client = new AWSAppSyncClient({
  url: appSyncConfig.graphqlEndpoint,
  region: appSyncConfig.region,
  auth: {
    type: appSyncConfig.authenticationType,
    apiKey: appSyncConfig.apiKey,
  }
});

AppSyncのデータと連携するコンポーネントをApolloProviderRehydratedに含めApolloProviderに対して、AppSyncClientを渡しています。

App.js
class App extends Component {
  render() {
    return (
      <ApolloProvider client={client}>
        <Rehydrated>
          <div className="App">
            <header className="App-header">
              <h1 className="App-title">AWS AppSync Todo</h1>
            </header>
            <TodoListWithData />
          </div>
        </Rehydrated>
      </ApolloProvider>
    );
  }
}

GraphQLクエリの作成

graphql-tagのgqlメソッドを使って、クエリを定義します。今回は、src/GraphQL以下に作成しました。

Todo全件取得のQuery

QueryGetTodos.js
import gql from "graphql-tag";

export default gql(`
query {
  getTodos {
    id
    title
    description
    completed
  }
}`);

Todo作成のMutation

MutationAddTodo.js
import gql from "graphql-tag";

export default gql(`
mutation addTodo($id: ID!, $title: String, $description: String, $completed: Boolean) {
  addTodo(
    id: $id
    title: $title
    description: $description
    completed: $completed
  ) {
    id
    title
    description
    completed
  }
}`);

Todo更新のMutation

MutationUpdateTodo.js
import gql from "graphql-tag";

export default gql(`
mutation updateTodo($id: ID!, $title: String, $description: String, $completed: Boolean) {
  updateTodo(
    id: $id
    title: $title
    description: $description
    completed: $completed
  ) {
    id
    title
    description
    completed
  }
}`);

Todo削除のMutation

MutationDeleteTodo.js
import gql from "graphql-tag";

export default gql(`
mutation deleteTodo($id: ID!) {
  deleteTodo(id: $id) {
    id
    title
    description
    completed
  }
}`);

ToDoList Componentの実装

今回は、ざっくり1つのComponentにTodoリストの全機能をまとめてしまいます。
src/Components以下に、TodoList.jsを作成しました。

AWS AppSyncとComponentの連携

AWS AppSyncのGraphQL APIからとReact Componentを連携するために、react-apolloを使用します。

react-apolloのgraphqlメソッドの引数にComponentを渡すと、ComponentのpropsでGraphQL APIから取得したデータを取得できるComponentを受け取ることができます。

graphql
const TodoListWithData = graphql(QueryGetTodos)(TodoList);

また、複数のQuery、MutationとComponentを連携する場合には、react-apolloのcomposeメソッドを使用します。
実際には、それぞれにオプションなどを指定するため、あくまでイメージです。

compose
const TodoListWithData = compose(
  graphql(QueryGetTodos),
  graphql(MutationAddTodo),
  graphql(MutationUpdateTodo),
  graphql(MutationDeleteTodo),
)(TodoList);

実際に、それぞれのQuery、Mutationを紐付ける部分は次の通りです。

TodoList.js
export default compose(
  // 全件取得Query
  graphql(QueryGetTodos, {  // あらかじめ定義したGraphQLクエリを使用
    options: {
      fetchPolicy: 'cache-and-network'
    },
    props: (props) => ({
      todos: props.data.getTodos
    })
  }),
  // 追加Mutation
  graphql(AddTodoMutation, {  // あらかじめ定義したGraphQLクエリを使用
    props: (props) => ({
      onAdd: (todo) => {
        props.mutate({
          variables: { ...todo },
          // APIからのレスポンスが返ってくるまえにpropsに反映する値を設定
          optimisticResponse: () => ({ addTodo: { ...todo, __typename: 'Todo' } })
        })
      }
    }),
    options: {
      // 追加の後に全件リストを更新するアクション
      refetchQueries: [{ query: QueryGetTodos }],
      update: (proxy, { data: { addTodo } }) => {
        const query = QueryGetTodos;
        const data = proxy.readQuery({ query });

        data.getTodos.push(addTodo);

        proxy.writeQuery({ query, data });
      }
    }
  }),
  // 状態更新(チェック)Mutation
  graphql(UpdateTodoMutation, {  // あらかじめ定義したGraphQLクエリを使用
    props: (props) => ({
      onCheck: (todo) => {
        props.mutate({
          variables: { id: todo.id, title: todo.title, description: todo.description, completed: !todo.completed },
          // APIからのレスポンスが返ってくるまえにpropsに反映する値を設定
          optimisticResponse: () => ({ updateTodo: { id: todo.id, title: todo.title, description: todo.description, completed: !todo.completed, __typename: 'Todo' } })
        })
      }
    }),
    options: {
      // 更新の後に全件リストを更新するアクション
      refetchQueries: [{ query: QueryGetTodos }],
      update: (proxy, { data: { updateTodo } }) => {
        const query = QueryGetTodos;
        const data = proxy.readQuery({ query });

        data.getTodos = data.getTodos.map(todo => todo.id !== updateTodo.id ? todo : { ...updateTodo });

        proxy.writeQuery({ query, data });
      }
    }
  }),
  // 削除Mutation
  graphql(DeleteTodoMutation, {  // あらかじめ定義したGraphQLクエリを使用
    props: (props) => ({
      onDelete: (todo) => props.mutate({
        variables: { id: todo.id },
        // APIからのレスポンスが返ってくるまえにpropsに反映する値を設定
        optimisticResponse: () => ({ deleteTodo: { ...todo, __typename: 'Todo' } }),
      })
    }),
    options: {
      // 削除の後に全件リストを更新するアクション
      refetchQueries: [{ query: QueryGetTodos }],
      update: (proxy, { data: { deleteTodo: { id } } }) => {
        const query = QueryGetTodos;
        const data = proxy.readQuery({ query });

        data.getTodos = data.getTodos.filter(todo => todo.id !== id);

        proxy.writeQuery({ query, data });
      }
    }
  })
)(TodoList);

それ以外の部分は次の通りです。

TodoList.js
class TodoList extends Component {

  constructor(props) {
    super(props);
    this.state = {
      todo: {
        title: '',
        description: ''
      },
    };
  }

  // propsの初期値を設定
  static defaultProps = {
      todos: [],
      onAdd: () => null,
      onDelete: () => null,
      onUpdate: () => null,
  }

  todoForm = () => (
    <div>
      <span><input type="text" placeholder="タイトル" value={this.state.todo.title} onChange={this.handleChange.bind(this, 'title')} /></span>
      <span><input type="text" placeholder="説明" value={this.state.todo.description} onChange={this.handleChange.bind(this, 'description')} /></span>
      <button onClick={this.handleOnAdd}>追加</button>
    </div>
  );

  renderTodo = (todo) => (
    <li key={todo.id}>
      <input type="checkbox"checked={todo.completed} onChange={this.handleCheck.bind(this, todo)} />
      {!todo.completed && todo.title}
      {todo.completed && (<s>{todo.title}</s>)}
      <button onClick={this.handleOnDelete.bind(this, todo)}>削除</button>
    </li>
    );

  handleChange = (field, { target: { value }}) => {
    const { todo } = this.state;
    todo[field] = value;
    this.setState({ todo });
  }

  handleOnAdd = () => {
    if (!this.state.todo.title || !this.state.todo.description) {
      return;
    }
    const uuid = uuidv4();
    const newTodo = {
      id: uuid,
      title: this.state.todo.title,
      description: this.state.todo.description,
      completed: false
    }
    this.props.onAdd(newTodo);

    const { todo } = this.state;
    todo.title = '';
    todo.description = '';
    this.setState({ todo });
  }

  handleCheck = (todo) => {
    this.props.onCheck(todo);
  }

  handleOnDelete = (todo) => {
    this.props.onDelete(todo);
  }

  render() {
    const { todos } = this.props;
    return (
      <Fragment>
        {this.todoForm()}
        <ul>
          {todos.map(this.renderTodo)}
        </ul>
      </Fragment>
    );
  }
}

参考

Building a ReactJS Client App -AWS AppSync
ReactとApolloを使ってGithub GraphQL APIを試してみる -Qiita
APOLLO CLIENT -Apollo

まとめ

クライアント画の実装に関しては、react-apolloに依存する部分が多く、AWS AppSyncとReactの組み合わせをガッツリ使っていこうとすると、react-apolloのヘルパーメソッドやキャッシュなどのオプション周りを詳しく見ていく必要があるかと思います。
(逆にそれ以外の部分は、aws-appsync-reactがよしなにやってくれるので、気にする必要はない)
今回は、GraphQLクエリにQueryとMutationのみを使用しましたが、機会があれば、Subscriptionを使ってリアルタイムでサーバー側と通信を行うパターンも試してみたいと思います。

続きを読む

Hadoop dev with Aws and Spark Implementation:Proxy

さらに表示: amazon machine learning vs spark, aws spark tutorial, aws machine learning collaborative filtering, azure recommender systems, aws collaborative filtering, aws recommendation engine 2017, aws machine learning recommendation engine, build a recommendation engine using amazon … 続きを読む

Linux のログイン・ログオフ履歴を Cloudwatch Logs に送信する

サマリ

Linux のログイン/ログオフの履歴(だけ)を Cloudwatch Logs に送りたかった。
rsyslog から sshd のログだけ抽出して Cloudwatch Logs Agent で送った。できた。

要件

Linux へのログイン・ログオフの履歴を Cloudwatch Logs に保存する必要があり、Cloudwatch Logs Agent をインストールして /var/log/secure を Cloudwatch Logs に送信する。
ただし、トラフィック量の都合で secure 全て送るのはよろしくないのでいい感じに絞ったものを送信したい。

SSH ログイン時に出力されるログには2種類あり、

  1. sshd プロセスが出力する rsyslog

    • /var/log/secure
  2. login プロセス出力するログ達(バイナリ形式)
    • /var/log/wtmp (ログイン成功ログ)

      • last コマンドで表示、新しいものが上で並ぶ
    • /var/log/btmp (ログイン失敗ログ)
      • lastb コマンドで表示、新しいものが上で並ぶ

送信するにはテキストである必要があるため、

  1. rsyslog からうまいこと sshd プロセスのログだけを別ファイルにする

    • rsyslog で出力されたログをCloudwatch Logs Agent で送信する
  2. last/lastbコマンドを実行し、結果をログファイルに出力するシェルスクリプトを作成する。その際、時系列降順に直す必要がある。
    • cronで定期的に実行し、ログをCloudwatch Logs Agent で送信する

の2パターン考えられるが、楽そうな前者を試す。

設定手順

環境

  • Red Hat Enterprise Linux 7.4 (HVM)
  • awscli-cwlogs 1.4.4

SSHログの抽出

適当な EC2 インスタンスを起動。

要件としては、rsyslog の secure ログ /var/log/secure| grep 'sshd'したような結果が出力できればよさそう。そのほかの secure ログはいらない。

console
$ sudo cat /var/log/secure | grep 'sshd'
略
Jan 23 19:41:46 HOSTNAME sshd[5106]: Server listening on 0.0.0.0 port 22.
Jan 23 19:41:46 HOSTNAME sshd[5106]: Server listening on :: port 22.
Jan 23 20:40:54 HOSTNAME sshd[1976]: pam_unix(sshd:session): session closed for user ec2-user
Jan 23 20:47:46 HOSTNAME sshd[4914]: Accepted publickey for ec2-user from 10.0.0.2 port 61646 ssh2: RSA SHA256:xxx
Jan 23 20:47:46 HOSTNAME sshd[4914]: pam_unix(sshd:session): session opened for user ec2-user by (uid=0)
Jan 23 20:49:12 HOSTNAME sshd[4914]: pam_unix(sshd:session): session closed for user ec2-user

rsysgにはプロパティベース フィルタというものがあり、 :property, [!]compare-operation, "value"
programname でフィルタがかけられる。これを利用すれば特定のプロセスのログだけ別ファイルに出力することが可能。
なので rsyslog の設定をしていく。secure_sshd という新しいログファイルに sshd プロセスのログだけを出力する設定を追記。

/etc/rsyslog.conf
# sshd ログを別ファイルにも出力
:programname, isequal, "sshd" /var/log/secure_sshd
console
sudo service rsyslog restart

ログイン・ログオフしてから良い感じにログが出ていること確認できた。

console
$ sudo cat /var/log/secure_sshd
Jan 24 03:08:55 HOSTNAME sshd[9308]: Accepted publickey for ec2-user from 10.0.0.3 port 60196 ssh2: RSA SHA256:xxx
Jan 24 03:08:55 HOSTNAME sshd[9308]: pam_unix(sshd:session): session opened for user ec2-user by (uid=0)
Jan 24 03:09:14 HOSTNAME sshd[9308]: pam_unix(sshd:session): session closed for user ec2-user

Cloudwatch Agent 側設定

EC2インスタンスに CloudwatchLogs 用のポリシーをアタッチ。

Send2Cloudwatch
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogStreams"
    ],
      "Resource": [
        "arn:aws:logs:*:*:*"
    ]
  }
 ]
}

パッケージ更新、awslogsインストール

console
sudo yum update -y
# ubuntu,centos,redhat はこう
curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
sudo python ./awslogs-agent-setup.py --region us-east-1
# Amazon Linux ならこっち
# sudo yum install awslogs

バージョン確認

console
$ /var/awslogs/bin/awslogs-version.sh
略
/etc/cron.d/awslogs_log_rotate version:
# Version: 1.4.3
CloudWatch Logs Plugin Version:
You are using pip version 6.1.1, however version 9.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
---
Metadata-Version: 1.1
Name: awscli-cwlogs
Version: 1.4.4
Summary: AWSCLI CloudWatch Logs plugin
Home-page: http://aws.amazon.com/cli/
Author: Amazon
Author-email: UNKNOWN
License: Amazon Software License
Location: /var/awslogs/lib/python2.7/site-packages
Requires: awscli, six, python-dateutil
AWS CLI Version

ログファイル送信設定、先ほどの secure_sshd を指定する

/var/awslogs/etc/awslogs.conf
# 元のmessageログ送信は今回使わないのでコメントアウト
# [/var/log/messages]
# datetime_format = %b %d %H:%M:%S
# file = /var/log/messages
# buffer_duration = 5000
# log_stream_name = {instance_id}
# initial_position = start_of_file
# log_group_name = /var/log/messages

# 普通にsecureログ送るならこう
# [/var/log/secure]
# datetime_format = %b %d %H:%M:%S
# file = /var/log/secure
# buffer_duration = 5000
# log_stream_name = {instance_id}
# initial_position = start_of_file
# log_group_name = /var/log/secure

[/var/log/secure_sshd]
datetime_format = %b %d %H:%M:%S
file = /var/log/secure_sshd
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/secure_sshd

必要に応じてプロキシ設定

/var/awslogs/etc/proxy.conf
HTTP_PROXY=proxyserver:8080
HTTPS_PROXY=proxyserver:8080
NO_PROXY=

サービス再起動&起動設定

console
sudo service awslogs start
sudo chkconfig awslogs on

Logs への送信ログ確認するなら

console
sudo tail /var/log/awslogs.log

動きました

image.png

参考

CloudWatch Logs エージェントのリファレンス – Amazon CloudWatch ログ
クイックスタート: 実行中の EC2 Linux インスタンスに CloudWatch Logs エージェントをインストールして設定する – Amazon CloudWatch ログ
Linux環境設定/sshによる不正アクセスを確認する – Linuxと過ごす
Rsyslog – Wikinote
システム管理の基礎 syslogdの設定をマスターしよう:Linux管理者への道(3) – @IT
必読!ログファイルとディレクトリ | Think IT(シンクイット)

続きを読む

ElasticBeanstalk 上の NodeJS が80番ポートへのアクセスを受けるまでの流れ

Elastic Beanstalk の NodeJS Platform でアプリケーションを作成すると
80 ポートでアクセスできる Web アプリケーションが簡単に出来上がる。

しかし NodeJS は 80 番ポートとは異なるポート 8081 番を Listen しており、
どういった経路で 80 番からのアクセスを受けているのか調べた。

ポート転送の流れ (結論)

  • iptables (PREROUTING)

    • 転送ポート: 80 –> 8080
  • nginx (Proxy)
    • 転送ポート: 8080 –> 8081
  • node (Server)

まず 80 番ポートへのアクセスを iptables が 8080 に変換し、
次に LISTEN 8080 の状態で起動している nginx が 8081 に転送、
次に LISTEN 8081 の状態で起動している NodeJS がリクエストを処理する。

一般的に 0 ~ 1023 番のポートは「well known port」と呼ばれ、Linux では root 権限がないとポートの Listen が出来ない。

root ユーザで nodejs プロセスを動かすことは危険だが、
この構成にすることで nodejs を一般ユーザで起動することが出来る。

ElasticBeanstalk では nodejs プロセスは nodejs ユーザが起動していた。

上記の情報元

EC2 インスタンスに入って上記を調べた時のメモ。
関係のない出力内容は一部割愛。

iptables の設定

80 で受けたアクセスを 8080 へ転送する NAT が作成されている。
PREROUTING チェインのため EC2 インスタンスがアクセスを受けた時にまず処理される。

$ sudo iptables -t nat -S PREROUTING -v
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -c 0 0 -j REDIRECT --to-ports 8080

nginx の設定

8080 で受けたアクセスを 8081 に転送するプロキシ設定。
本題とは関係ないが通信の gzip 圧縮・展開もこの層で行われる。

$ cat /etc/nginx/conf.d/00_elastic_beanstalk_proxy.conf
upstream nodejs {
    server 127.0.0.1:8081;
}

server {
    listen 8080;

    location / {
        proxy_pass  http://nodejs;
        proxy_set_header   Connection "";
        proxy_http_version 1.1;
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

gzip on;
gzip_comp_level 4;
gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;

関連プロセスの Port Listen 状況

node が 8081, nginx が 8080 をそれぞれ Listen していることが分かる。

$ sudo netstat -anp
tcp        0      0 :::8081                     :::*                        LISTEN      2969/node
tcp        0      0 0.0.0.0:8080                0.0.0.0:*                   LISTEN      2977/nginx

NodeJS 起動時の環境変数

PORT=8081 とあるので nodejs は 8081 を Listen する。

$ sudo od -S1 -An /proc/$(ps aux | grep ^nodejs | perl -anlE 'say $F[1]' | tail -1)/environ
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin:/opt/elasticbeanstalk/node-install/node-v6.11.5-linux-x64/bin
SHELL=/bin/sh
TERM=linux
EB_NODE_COMMAND=node app.js
USER=nodejs
PWD=/var/app/current
HOME=/tmp
SHLVL=1
UPSTART_INSTANCE=
LOGNAME=nodejs
PORT=8081
UPSTART_JOB=nodejs
NODE_HOME=/opt/elasticbeanstalk/node-install/node-v6.11.5-linux-x64
_=/opt/elasticbeanstalk/node-install/node-v6.11.5-linux-x64/bin/node

NodeJS のデフォルトのアプリケーションソース

上記で分かるように環境変数 PORT が定義されているため、
8081 ポートが Listen される。

app.js
var port = process.env.PORT || 3000,
    http = require('http'),
    fs = require('fs'),
    html = fs.readFileSync('index.html');

var log = function(entry) {
    fs.appendFileSync('/tmp/sample-app.log', new Date().toISOString() + ' - ' + entry + 'n');
};

var server = http.createServer(function (req, res) {
    // 省略
});

続きを読む

t2.microインスタンスでWindowsは使い物になるのか?

ICDP(田舎クラウドデザインパターン)的なネタ再び。

概要

AWS EC2 t2.micro インスタンスのシステム資源は非常に乏しい。
AWS無料利用枠でウィンドウズも対象だけど、本当に使い物になるのか?

目的

t2.microインスタンスへWindows Server 2008R2をインストールしてソフトウェアを起動しようとしたところ、 Out of Memory で起動不能であった。
メモリ1GB、連続して演算できない制限付きのCPU能力で、ウィンドウズを使用するには厳しい。
動作させたいソフトウェアは必要メモリ500MBのため、なんとか使えるようにすることを目的とする。

要件

  • AMI
    Windows_Server-2008-R2_SP1-Japanese-64Bit-Base-2017.11.29 – ami-95d06bf3

  • ページファイル(スワップ)無しで使う。
    スワップが発生したら実用にならないためページファイルは無しとする。
    これはスワップ処理にはCPU時間を消費するため、CPU時間に制限があるt2系インスタンスでは動作が間欠的に停止したり、操作不能に陥ったりするからである。

現状

Windows Server 2008R2 をインストールして起動した状態はこのようになっている。
t2a.jpg

消費メモリは959MB。
メモリ1GBしか無いのに消費メモリがこの状況では無理もない。殆ど空きがない。
40MBではメモリ不足で起動不能となるのは当然であろう。

対処

タスクマネージャでメモリ使用状況を見て削減できそうなプロセスを調べる。
t2b.jpg

TrustedInstaller.exe が460MBも使用している。
これは何かと調べると、Windows Modules Installerサービスのようだ。
Windows Update関連のプログラムで、停止させると更新に失敗するが通常は問題無いので停止させてみた。

無効に設定したサービス

先の大物を含め、無効に設定したサービスは以下の通り。
ただしこれを行うとWindows Updateが失敗するので行う場合は手動で起動し対処すること。

  • Windows Modules Installer
  • Windows Update
  • WinHttp Web proxy Auto-Discovery Service

また、AWSオリジナルの制御機能を使わないのであれば以下も無効にできる。
こちらは計20MB程度の削減にしかならないのでお好みで。

  • Amazon SSM Agent
  • AWS Lite Guest Agent
  • Ec2Config

対処した結果

t2c.JPG

消費メモリが400MB程度となり、600MBの空きを確保できた。

結論

かろうじて要件を満たし動作可能な環境を構築できた。
しかし、リソースには余裕が無いためMackerel等で常時監視した方が良いと思われる。

続きを読む

カップル向けのサービスをメンテフリーで有名なserverless構成で出した話

「Glance(グランス)」 ~カップルのためのYes/No枕アプリ~

2018/01/03より、「Yes/No枕をアプリで」というコンセプトの元に作られたアプリをリリースしましたー!

結構、謎仕様が多くて使い所も不明ですが、
9月ぐらいの「八耐|八時間耐久製作会」というイベントでアイデアから本日のリリースに至りました。

itunes.apple.com_jp_app_glance-yes-no%E3%81%BE%E3%81%8F%E3%82%89_id1294641754_l=ja&ls=1&mt=8.png

https://itunes.apple.com/jp/app/glance-yes-no%E3%81%BE%E3%81%8F%E3%82%89/id1294641754?l=ja&ls=1&mt=8

機能

  • アプリアイコンが動的に変わる、Yes/No枕アプリ

特徴

  • iOS10.3からの機能で、アプリアイコンがYes/Noに動的に変わり、お互いにステータスが見れるというコンセプトです。
  • サーバーサイドはserverless frameworkで
    LambdaとDynamoDBを使っており、メンテコストはほぼ0(ゼロ)

構成

  • アプリ Swift4.0
  • サーバー serverless framework
    • DynamoDB
    • Lambda
    • API Gateway

serverless frameworkとは

  • 「AWS Lambda」と「AWS API Gateway」を利用したサーバレスなアプリケーションを構築するためのツールです。
  • AWSコンソールからだとボタン操作の履歴が残らないですが、serverless frameworkだと全てコードベースで管理できます。

サーバーレスのメリット

  • 管理するサーバーが無いのでサーバーダウンの概念がありません。
  • とにかく安い!
  • 保守メンテが楽でセキュリテイパッチやサーバー管理などのメンテが不要
  • 詳しくはserverlessの魅力を御覧ください

Lambda上でNode.js + Expressがおすすめ

  • API Gatewayでpath管理できますが、serverless + expressのプラグインがあるのでそれに任せたほうが圧倒的に楽になります。

serverless.ymlを晒しとく

  • eventsはanyですべてnodeのExpressに投げます。
serverless.yml
service: yesnoapp

custom:
  defaultStage: dev

provider:
  name: aws
  runtime: nodejs6.10
  profile: yesnoapp
  stage: ${opt:stage, self:custom.defaultStage}
  region: ap-northeast-1
  memorySize: 100
  timeout: 2
  iamRoleStatements:
      - Effect: Allow
        Action:
          - dynamodb:DescribeTable
          - dynamodb:Query
          - dynamodb:Scan
          - dynamodb:GetItem
          - dynamodb:PutItem
          - dynamodb:UpdateItem
          - dynamodb:DeleteItem
        Resource: "arn:aws:dynamodb:${self:provider.region}:*:table/*"

package:
  exclude:
    - .serverless
    - .webpack
    - coverage
    - .babelrc
    - .eslintignore
    - .eslintrc
    - .gitignore
    - LICENSE
    - package.json
    - README.md
    - serverless.yml
    - webpack.config.js


functions:
  app:
    handler: handler.app
    events:
      - http: any {proxy+}

resources:
  Resources:
    YesNoAPPDynamoDbTable:
      Type: 'AWS::DynamoDB::Table'
      DeletionPolicy: Retain
      Properties:
        AttributeDefinitions:
          -
            AttributeName: device_token
            AttributeType: S
        KeySchema:
          -
            AttributeName: device_token
            KeyType: HASH
        ProvisionedThroughput:
          ReadCapacityUnits: 1
          WriteCapacityUnits: 1
        TableName: "Users"

とまあ、こんな感じでExpressが動く!

  • メンテフリー!コストフリー!みんなハッピー!

良かったこと/悪かったこと

ハッカソンのような短期開発には向いている

  • 開発のスタートダッシュが早く、ハッカソンのような短期即本番には向いているといえます。

運用後も安心な価格とコスト

  • ハッカソンで作った作品なので、アクセスはほぼ見込まれません。t2インスタンスなどは、固定でどんどんお金がかかりますが、料金はアクセスが増えた分だけだし、無料枠も十分あるので運用後もずっと残して置けるでしょう。

バズってもなお安心

  • バズることはほぼないですが、もし万が一バズったとしても、サーバーレス設計なら理論上無限スケールで対応することができます。

中盤がきつい

  • スタートダッシュは早いものの、だんだんこだわって作り出すと、Railsだったらこうできるのに…や、DynamoDBだからテーブルわけなくちゃ…NoSQLの苦悩など、中盤のブラッシュアップ期間は忍耐が必要そうです。

まとめ

  • サーバーレス設計は、開発速度が早く安い。とくにハッカソンイベントでは効果を発揮するのでおすすめです!という話でした!

参考

今回参加した八耐の紹介

『八耐』とは

  • 『八耐:八時間耐久作品制作会(仮)』は、8時間でゲームやCG、映像を制作し、参加者全員で発表するイベントです。
  • イベントの最後に発表と試遊会を通じて、新しい繋がりや見知らぬクリエーター同士の交流を深めるイベントにもなっています。
  • 東京と福岡会場があります。私は毎月、東京会場で参加しておりますのでぜひ!
  • http://www.daihachitai.com/index.php/about

続きを読む

AWSでElastic Stack – 前回の続き Kibana Filebeatのアップグレード

はじめに

前回、KibanaとFilebeatもアップグレードするような記事を書いたのですが、途中で力尽きてElasticsearchのアップグレードで終わってしまったので、短くなりますが、KibanaとFilebeatもアップグレードしたいと思います。
前回の記事(前回中途半端で申し訳ないですが)の構成を参照して頂ければと思います。

AWSの小ネタ

本題とは関係ありませんが、一応AWSタグを付けているので、AWSで悩んだ話について。

IAMロールで起動したEC2インスタンスのプロキシ環境下にて、プロキシサーバのログに以下のログが大量に出力されていました。

TCP_MISS/404 609 GET http://169.254.169.254/latest/meta-data/network/interfaces/macs/xx:xx:xx:xx:xx:xx/local-ipv4s - HIER_DIRECT/169.254.169.254 text/html

それでxxになっているMACアドレスを持つサーバを調べると以下のログが連続して大量に出力されていました。

ec2net: [get_meta] Trying to get http://169.254.169.254/latest/meta-data/network/interfaces/macs/xx:xx:xx:xx:xx:xx/local-ipv4s

恐らくec2がmetadataを取りにいくのですが、プロキシサーバを経由してしまうせいで、
ご本人じゃありませんよとAWSのmetadataサーバに拒否されているんでしょうと推測しました。

プロキシ環境下では169.254.169.254はプロキシを経由しないようにNO_PROXYの設定を設定します。
http://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-http-proxy.html

自分もこの設定を入れていましたので、設定が有効になっていないかと悩まされることになりました。そこで一旦、exportしているプロキシの設定を削除しましたが、
やっぱりプロキシサーバを経由することを止められませんでした。

そこで他のプロキシを利用する設定を考えたところ、そういえば最初は全てのアクセスをプロキシ経由にするつもりが無くて、yumやwget,curlくらいしかInternetへのアクセスをしないので、それぞれのコンフィグにプロキシの設定を個別に書いていたなと思い至りました。

それで結局当たったのは、curlの.curlrcのプロキシの設定でした。
ここにはNO_PROXYの設定は書いていませんでした。
ここの設定が有効でプロキシサーバ経由でアクセスしているとは・・
ec2がmetadataを取得する際にはcurlで取りにいっているってことですかね?(分かってない)

1.アップグレード作業

では前回やり残したKibanaとFilebeatのアップグレード作業を実施したいと思います。

1.1.事前準備

公式のドキュメントを参考にしながら進めていきます。
Kibana
https://www.elastic.co/guide/en/kibana/current/rpm.html
Filebeat
https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html

あれ・・・前回見た時は6.0だったのに、どんどん更新されていきますね。

1.1.1.GPGキーのインストール

KibanaとFilebeatをインストールしているそれぞれのサーバにて実施します。

Kibanaをインストールしたサーバ(srv1)

# rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

Filebeatをインストールしたサーバ(srv4)

# rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch

1.1.2.リポジトリの修正

6.0系のリポジトリを用意します。

Kibana

# vi /etc/yum.repos.d/kibana.repo
[kibana-6.x]
name=Kibana repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

Filebeat

# vi /etc/yum.repos.d/beats.repo
[elastic-6.x]
name=Elastic repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

1.2.アップグレード

Kibana

# yum update kibana
Loaded plugins: priorities, update-motd, upgrade-helper
42 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package kibana.x86_64 0:5.6.2-1 will be updated
---> Package kibana.x86_64 0:6.1.1-1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================
 Package                     Arch                        Version                        Repository                       Size
==============================================================================================================================
Updating:
 kibana                      x86_64                      6.1.1-1                        kibana-6.x                       63 M

Transaction Summary
==============================================================================================================================
Upgrade  1 Package

Total download size: 63 M
Is this ok [y/d/N]: y

Filebeat

# yum update filebeat
Loaded plugins: priorities, update-motd, upgrade-helper
Resolving Dependencies
--> Running transaction check
---> Package filebeat.x86_64 0:1.3.1-1 will be updated
---> Package filebeat.x86_64 0:6.1.1-1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

===================================================================================================================================================================================================
 Package                                        Arch                                         Version                                       Repository                                         Size
===================================================================================================================================================================================================
Updating:
 filebeat                                       x86_64                                       6.1.1-1                                       elastic-6.x                                        12 M

Transaction Summary
===================================================================================================================================================================================================
Upgrade  1 Package

Total download size: 12 M
Is this ok [y/d/N]: y

1.3.サービスの再起動

Kibana

# service kibana restart
kibana started

Filebeat

 service filebeat restart
2017/12/25 08:46:58.653044 beat.go:436: INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017/12/25 08:46:58.653113 metrics.go:23: INFO Metrics logging every 30s
2017/12/25 08:46:58.653234 beat.go:443: INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017/12/25 08:46:58.653256 beat.go:203: INFO Setup Beat: filebeat; Version: 6.1.1
2017/12/25 08:46:58.653386 client.go:123: INFO Elasticsearch url: http://192.100.0.4:9200
2017/12/25 08:46:58.653586 module.go:76: INFO Beat name: ip-192-100-0-36
Config OK
Stopping filebeat:                                         [  OK  ]
Starting filebeat: 2017/12/25 08:46:58.773001 beat.go:436: INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017/12/25 08:46:58.773063 metrics.go:23: INFO Metrics logging every 30s
2017/12/25 08:46:58.773112 beat.go:443: INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017/12/25 08:46:58.773132 beat.go:203: INFO Setup Beat: filebeat; Version: 6.1.1
2017/12/25 08:46:58.773280 client.go:123: INFO Elasticsearch url: http://192.100.0.4:9200
2017/12/25 08:46:58.773479 module.go:76: INFO Beat name: ip-192-100-0-36
Config OK
                                                           [  OK  ]

1.4.確認

KibanaとFilebeatのバージョンやログが取れているか等確認します。

Filebeatアップグレード前

# filebeat -version
filebeat version 1.3.1 (amd64)

Filebeatアップグレード後

# filebeat -version
filebeat version 6.1.1 (amd64), libbeat 6.1.1

Kibanaアップグレード前
kibana-version.png

kibanaアップグレード後
kibana6.1ver.png

あ~~ elasticsearchとバージョンが一致しないって怒られてますね。
マイナーバージョンも一致が必要なのは作業的に面倒ですね・・

というわけでまた前回の記事と同じようにアップグレードしてきました。

# curl -XGET 'localhost:9200/'
{
  "name" : "node001",
  "cluster_name" : "my-cluster",
  "cluster_uuid" : "e06BKBFFSpiSkFwNT3kWLw",
  "version" : {
    "number" : "6.1.1",
    "build_hash" : "bd92e7f",
    "build_date" : "2017-12-17T20:23:25.338Z",
    "build_snapshot" : false,
    "lucene_version" : "7.1.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

# curl -XGET 'http://localhost:9200/_cat/plugins?v'
name    component         version
node002 analysis-kuromoji 6.1.1
node002 x-pack            6.1.1
node003 analysis-kuromoji 6.1.1
node003 x-pack            6.1.1
node001 analysis-kuromoji 6.1.1
node001 x-pack            6.1.1

改めてKibanaを確認してみます。

kibana6-1.png

エラー直りました。通常のログイン後の画面に。
先ほどのエラー画面だから画面の色合いが違うのかと思っていたのですが、普通に落ち着いた感じになっております。
改めてバージョンを確認します。

kibana_ver6-1.png

OKですね。

では、次にfilebeatからデータが送られているかを確認します。

filebeat1.png

(新しいデータが)有りません

そこでfilebeatのログを確認してみたところ・・・

2017-12-27T07:53:01Z INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017-12-27T07:53:01Z INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017-12-27T07:53:01Z INFO Metrics logging every 30s
2017-12-27T07:53:01Z INFO Setup Beat: filebeat; Version: 6.1.1
2017-12-27T07:53:01Z INFO Elasticsearch url: http://192.100.0.4:9200
2017-12-27T07:53:01Z INFO Beat name: ip-192-100-0-36
2017-12-27T07:53:01Z INFO filebeat start running.
2017-12-27T07:53:01Z INFO Registry file set to: /var/lib/filebeat/registry
2017-12-27T07:53:01Z INFO Loading registrar data from /var/lib/filebeat/registry
2017-12-27T07:53:01Z INFO Total non-zero values:  beat.info.uptime.ms=3 beat.memstats.gc_next=4473924 beat.memstats.memory_alloc=3081016 beat.memstats.memory_total=3081016 filebeat.harvester.open_files=0 filebeat.harvester.running=0 libbeat.config.module.running=0 libbeat.output.type=elasticsearch libbeat.pipeline.clients=0 libbeat.pipeline.events.active=0 registrar.states.current=0
2017-12-27T07:53:01Z INFO Uptime: 3.375689ms
2017-12-27T07:53:01Z INFO filebeat stopped.
2017-12-27T07:53:01Z CRIT Exiting: Could not start registrar: Error loading state: Error decoding states: json: cannot unmarshal object into Go value of type []file.State

なんかエラー出て、filebeatが起動していない感じですかね。
そのエラーについて調べてみたところ、同じような状態になった方がおり、解決されていました。
https://discuss.elastic.co/t/exiting-could-not-start-registrar-error-loading-state-error-decoding-states-eof/74430

/var/lib/filebeat/registryを削除してから起動すれば良いようですね。
この環境は壊れても失うのは時間だけなので、やってみます。

# rm /var/lib/filebeat/registry
# service filebeat start
# cat /var/log/filebeat/filebeat

2017-12-27T08:14:08Z INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017-12-27T08:14:08Z INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017-12-27T08:14:08Z INFO Metrics logging every 30s
2017-12-27T08:14:08Z INFO Setup Beat: filebeat; Version: 6.1.1
2017-12-27T08:14:08Z INFO Elasticsearch url: http://192.100.0.4:9200
2017-12-27T08:14:08Z INFO Beat name: ip-192-100-0-36
2017-12-27T08:14:08Z INFO filebeat start running.
2017-12-27T08:14:08Z INFO No registry file found under: /var/lib/filebeat/registry. Creating a new registry file.
2017-12-27T08:14:08Z INFO Loading registrar data from /var/lib/filebeat/registry
2017-12-27T08:14:08Z INFO States Loaded from registrar: 0
2017-12-27T08:14:08Z INFO Loading Prospectors: 1
2017-12-27T08:14:08Z WARN DEPRECATED: input_type prospector config is deprecated. Use type instead. Will be removed in version: 6.0.0
2017-12-27T08:14:08Z INFO Starting Registrar
2017-12-27T08:14:08Z INFO Starting prospector of type: log; ID: 5240556406633074861
2017-12-27T08:14:08Z INFO Loading and starting Prospectors completed. Enabled prospectors: 1
2017-12-27T08:14:08Z INFO Harvester started for file: /var/log/secure
2017-12-27T08:14:09Z INFO Connected to Elasticsearch version 6.1.1
2017-12-27T08:14:09Z INFO Loading template for Elasticsearch version: 6.1.1
2017-12-27T08:14:09Z INFO Elasticsearch template with name 'filebeat-6.1.1' loaded

criticalなエラーは解決したようです。

しかしながら新たなエラーが。

2017-12-27T09:24:40Z ERR  Failed to publish events: temporary bulk send failure

そういえば、WARNもありますね。まずこれが気になるのでfilebeat.reference.ymlを見ながら修正してみました。

修正したfilebeat.yml

filebeat.modules:
- module: kafka
  log:
    enabled: true
filebeat.prospectors:
- type: log
  enabled: false
  paths:
    - /var/log/secure.log
output.elasticsearch:
  hosts: ["192.100.0.4:9200"]
setup.template.settings:
setup.kibana:
logging.to_files: true
logging.files:

filebeatを再起動することでWARNは消えました。

# cat /var/log/filebeat/filebeat
2017-12-27T09:49:12Z INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017-12-27T09:49:12Z INFO Metrics logging every 30s
2017-12-27T09:49:12Z INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017-12-27T09:49:12Z INFO Setup Beat: filebeat; Version: 6.1.1
2017-12-27T09:49:12Z INFO Elasticsearch url: http://192.100.0.4:9200
2017-12-27T09:49:12Z INFO Beat name: ip-192-100-0-36
2017-12-27T09:49:12Z INFO Enabled modules/filesets: kafka (log),  ()
2017-12-27T09:49:12Z INFO filebeat start running.
2017-12-27T09:49:12Z INFO Registry file set to: /var/lib/filebeat/registry
2017-12-27T09:49:12Z INFO Loading registrar data from /var/lib/filebeat/registry
2017-12-27T09:49:12Z INFO States Loaded from registrar: 1
2017-12-27T09:49:12Z INFO Loading Prospectors: 2
2017-12-27T09:49:12Z INFO Starting Registrar
2017-12-27T09:49:12Z INFO Starting prospector of type: log; ID: 15188226147135990593
2017-12-27T09:49:12Z INFO Loading and starting Prospectors completed. Enabled prospectors: 1

ERRが出力されるのかしばらく待ちます。

ERRも出なくなってました。しかし肝心のデータがkibanaで表示されない・・・

 おわりに

今回はこれで終わりにしたいと思います。
また来年続きやります・・・

こんなんばっかりや・・

続きを読む

Amazon Linux 2 に elasticsearchのbenchmarkツールrallyをインストールして、Amazon Elasticsearch Serviceの性能評価を行う.

Amazon Linux 2 に elasticsearchのbenchmarkツールrallyをインストールして、Amazon Elasticsearch Serviceの性能評価を行う.

Amazon Elasticssearch Serviceのパフォーマンスを調査する為に、Elasticsearchが提供するベンチマークツールのrallyを導入したEC2インスタンスを立ち上げ、性能評価を行います。

AMIは、最近発表された
Amazon Linux 2 LTS Candidate AMI 2017.12.0 (HVM), SSD Volume Type - ami-7707a10f
を利用してみます.

rallyは、python3上で動作する為、python3をインストールが必要になります.
AMIとして利用するAmazon Linux2に標準でインストールされているpythonは、version2系(Python 2.7.5)の為、python3系をインストールします。

$ sudo amazon-linux-extras install python3
$ python3 --version
Python 3.6.2

rally用のpython3環境とする為、python3の仮想環境を作ります.

$ python3 -m vent .py-esrally-venv
$ source .py-esrally-venv/bin/activate

rallyのインストール,実行時に不足するライブラリをインストールします.

$ sudo yum install gcc python3-devel git

rallyをインストールします.

(.py-esrally-venv) $ pip3 install esrally
(.py-esrally-venv) $ esrally configure
 # Press Enter to skip. 

elasticsearch serviceへのアクセスは、 Signature Version 4でアクセスする必要がある為、rallyから直接接続するすることができません. そこで Elasticsearch serviceにアクセスする為のproxyを立ち上げます.
今回は、 nodeベースのproxy aws-es-proxyを利用します.

nodeをインストールする為にnvmのインストールを行い、その後、nodeをインストールし、 aws-es-proxyを導入します.

(.py-esrally-venv) $ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash
(.py-esrally-venv) $ source .bashrc
(.py-esrally-venv) $ nvm install  v8.9.3
(.py-esrally-venv) $ npm init
(.py-esrally-venv) $ npm install --save aws-es-proxy

proxyを起動します.
なお、aws credentials情報(access_key_id, aws_secret_access_key)は、aws cliで設定しておいてください.

(.py-esrally-venv) $ node_modules/aws-es-proxy/bin/aws-es-proxy --port 9200 --profile default --region [region]  [endpoint]

proxy経由でElasticsearch Serviceにアクセスできることを確認します.

(.py-esrally-venv) $ curl http://localhost:9200/

rallyを実行します. target-hostsとして、proxyのアドレスを指定します。

(.py-esrally-venv) $ esrally --pipeline=benchmark-only --target-hosts=localhost:9200
    ____        ____
   / __ ____ _/ / /_  __
  / /_/ / __ `/ / / / / /
 / _, _/ /_/ / / / /_/ /
/_/ |_|__,_/_/_/__, /
                /____/

[INFO] Writing logs to /home/xxxxx/.rally/logs/rally_out_20171225T052238Z.log

************************************************************************
************** WARNING: A dark dungeon lies ahead of you  **************
************************************************************************

Rally does not have control over the configuration of the benchmarked
Elasticsearch cluster.

Be aware that results may be misleading due to problems with the setup.
Rally is also not able to gather lots of metrics at all (like CPU usage
of the benchmarked cluster) or may even produce misleading metrics (like
the index size).

************************************************************************
****** Use this pipeline only if you are aware of the tradeoffs.  ******
*************************** Watch your step! ***************************
************************************************************************
    :
  • 参考
    利用させていただいたproxy.
    https://github.com/joona/aws-es-proxy
    esrallyのドキュメント
    https://esrally.readthedocs.io/en/latest/index.html

  • 残件
    Amazon Elasticsearch Serviceの構成変更での性能評価を目的としている為、異なるproxyを利用する必要はないと想定しているが、go言語で実装された aws-es-proxyを使った場合の比較などもやっておくべきかもしれない. proxyで、パフォーマンスに差が出ると、性能指標の基準が低くなってしまうはず..
    trackを指定することで、異なるデータパターンでの評価を行うことができるので、サービスでの利用方法に近いtrackでの評価を実施すべき..デフォルト(オプション指定無)は、geonames.

  • 備考
    インスタンスタイプがt2.microだと、途中で異常終了してしまうようです. 評価中、CPU Creditを、使い切って途中で異常終了しました.
    また、Amazon Elasticsearch Service側の構成として、簡単に1台で立ち上げられますが、1台構成の場合、StatusがYellowの為、デフォルトでは、測定できません。 以下のようなERRORを出力して、測定が中断します.
    [ERROR] Cannot race. ('Could not execute benchmark', Cluster did not reach status [green]. Last reached status: [yellow])
    どうしても1台構成で実行する場合は、rally実行時に、 --cluster-health=yellow optionを付与する必要があります。

続きを読む

新しいCloudWatch AgentでEC2インスタンスのメモリ使用率を監視する

この記事は OpsJAWS Advent Calendar 2017 19日目の記事です。

はじめに

先日、新しいCloudWatch Agentが登場しました。
https://aws.amazon.com/jp/about-aws/whats-new/2017/12/amazon-cloudwatch-introduces-a-new-cloudwatch-agent-with-aws-systems-manager-integration-for-unified-metrics-and-logs-collection/

これまでディスク使用量やメモリ使用率といった仮想マシン上のメトリックについては
CloudWatch Monitoring Scripts 等 を設定してCloudWatchにデータを送信する必要がありました。
新しい Agent ではこれらのゲストOS上のメトリックについても収集できるようになっています。

収集可能なメトリックの一覧については以下のドキュメントを参照ください。
稼働対象(EC2 or On-premises)、OS、ログ取得レベルによっても取得出来る内容が異なります。
http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html#metrics-collected-by-CloudWatch-agent

やってみる

実際にAmazon Linuxサーバのメモリ使用率の監視設定を行ってみます。

IAMロールの作成

CloudWatch Agent を実行する EC2 インスタンスにアタッチする IAM ロールを事前に作成しておきます。

まず、以下の内容でポリシーを作成します。ポリシー名は任意に設定します。

CloudWatchAgentAdminPolicy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CloudWatchAgentAdminPolicy",
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "cloudwatch:PutMetricData",
                "ec2:DescribeTags",
                "logs:DescribeLogStreams",
                "logs:CreateLogGroup",
                "logs:PutLogEvents",
                "ssm:GetParameter",
                "ssm:PutParameter"
            ],
            "Resource": "*"
        }
    ]
}

新規のEC2用のIAMロールを作成し、上記のポリシーをアタッチします。
Agent の設定は AWS Systems Manager のパラメータストアに格納し、他サーバに展開させることが可能です。
上記例ではパラメータストアへの書き込みのため、ssm:PutParameter権限を付与しています。
通常、全てのインスタンスがパラメータストアへの書き込み権限を持つ必要はありませんので、
上記とは別に ssm:PutParameter を除いた一般用のIAMロールを別途作成することが望ましいです。

image.png

CloudWactch Agent のインストール

先ほど作成したIAMロールを、インストール対象のEC2インスタンスにアタッチします。

Agent のインストール方法は以下の2通りです。

  • AWS Systems Manager(ssm)によるインストール
  • CLI によるインストール

運用を考えると ssm でインストールを行うほうが楽ですが、
今回はAgentの基本的な操作を覚えるために、EC2インスタンスにログインし、CLIでインストールを行いました。

$ wget https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip
$ unzip AmazonCloudWatchAgent.zip
$ sudo ./install.sh

プロキシを設定する必要がある環境の場合は、
/opt/aws/amazon-cloudwatch-agent/etc/common-config.tomlに設定します。

common-config.tml
[proxy]
http_proxy = "{http_url}"
https_proxy = "{https_url}"
no_proxy = "{domain}"

Agent 設定

Agent 設定ファイルの作成

Agent の設定ファイルは、収集するメトリックやログファイルを指定したファイルです。
JSONで作成されたファイルをAgent 起動時にTOMLに変換する形になります。
手動で作成することもできますが、ここではウィザードを使用して作成します。

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

ウィザードでは以下を設定します。カッコ内は今回選択した内容です。
収集間隔は最短で1秒を指定できるようになっていますが、今回は60秒を選択しました。

  • インストール先のOS(Linux)
  • インストール先がEC2かオンプレミスか(EC2)
  • ホストのメトリクスを収集するか(yes)
  • CPUコア毎のメトリクスを収集するか(yes)
  • EC2ディメンションを全てのメトリクスに追加するか(yes)
  • メトリクスを収集する間隔(60s)
  • メトリクスの収集レベル(Standard)

ログファイル監視対象の設定

既にCloudWatch Logs を使用している環境の場合は、引き続きこのウィザードで設定を移行できます。
移行を行わない場合も監視対象のログファイルのパスを指定し、追加することができます。
ここでは デフォルト選択の syslog(/var/log/messages) を対象に指定し、ログの監視設定を完了します。

設定ファイルは /opt/aws/amazon-cloudwatch-agent/bin/config.json に保存されます。
今回、最終的な設定内容は以下のようになります。

config.json
{
    "logs": {
        "logs_collected": {
            "files": {
                "collect_list": [
                    {
                        "file_path": "/var/log/messages",
                        "log_group_name": "messages"
                    }
                ]
             }
         }
    },
    "metrics": {
        "append_dimensions": {
            "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
            "ImageId": "${aws:ImageId}",
            "InstanceId": "${aws:InstanceId}",
            "InstanceType": "${aws:InstanceType}"
        },
        "metrics_collected": {
            "cpu": {
                "measurement": [
                    "cpu_usage_idle",
                    "cpu_usage_iowait",
                    "cpu_usage_user",
                    "cpu_usage_system"
                ],
                "metrics_collection_interval": 60,
                "resources": [
                    "*"
                ],
                "totalcpu": false
             },
            "disk": {
                "measurement": [
                    "used_percent",
                    "inodes_free"
                ],
                "metrics_collection_interval": 60,
                "resources": [
                    "*"
                ]
            },
            "diskio": {
                "measurement": [
                    "io_time"
                ],
                "metrics_collection_interval": 60,
                "resources": [
                    "*"
                ]
            },
            "mem": {
                "measurement": [
                    "mem_used_percent"
                ],
                "metrics_collection_interval": 60
            },
            "swap": {
                "measurement": [
                    "swap_used_percent"
                ],
                "metrics_collection_interval": 60
            }
        }
    }
}

パラメータストアへの保存

ウィザードの最後に設定ファイルをSSM パラメータストアに保存するかの確認があります。
選択肢は全てデフォルトで問題ありません。

  • 設定ファイルを SSM パラメータストアに保存するか(yes)
  • パラメータストア名(agent-config-linux)
  • 保存先リージョン(ap-northeast-1)
  • AWSクレデンシャルの選択(From SDK)

aws cliで手動アップロードすることも可能です。

$ cd /opt/aws/amazon-cloudwatch-agent/bin/
$ aws ssm put-parameter --name "agent-config-linux" --type "String" --value file://config.json

AWS Systems Manger のコンソールを確認すると、パラメータストアが保存されていることが確認できます。

image.png

Agentの起動

SSMパラメータストアに保存した設定ファイルでAgentを起動してみます。

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c ssm:agent-config-linux -s
/opt/aws/amazon-cloudwatch-agent/bin/config-downloader --output-file /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json --download-source ssm:agent-config-linux --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml
Successfully fetched the config from parameter store ssm:agent-config-linux and saved in /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
Start configuration validation...
/opt/aws/amazon-cloudwatch-agent/bin/config-translator --input /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json --output /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml --mode ec2 --config /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml
Valid Json input schema.
Configuration validation first phase succeeded
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent -schematest -config /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml
Configuration validation second phase succeeded
Configuration validation succeeded
amazon-cloudwatch-agent start/running, process 2811

メッセージの内容から、JSONの設定ファイルが
/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml として保存されていることがわかります。

ログファイルは /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log に出力されています。
またAgentインストール時にサービス登録が行われていますが、

  • common-config.toml
  • amazon-cloudwatch-agent.toml

の2ファイルが存在しないと、OS起動時にAgentが正常に起動できないようです。

ステータス確認、および終了コマンドは以下のように行うことができます。
また amazon-cloudwatch-agent.toml が作成されている状態であれば、2回目以降の起動では
設定ファイルのフェッチは不要です。

# ステータス確認
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
{
  "status": "running",
  "starttime": "2017-12-19T01:43:56+0000",
  "version": "1.73.9"
}

# 停止
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a stop
amazon-cloudwatch-agent stop/waiting

# 起動
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a start
amazon-cloudwatch-agent start/running, process 3044

監視設定

コンソール上で取得したメトリックの確認および、アラームの設定を行います。

メトリックの確認

カスタム名前空間の CWAgent を選択します。
少しわかりにくいですが、それぞれのメトリックを確認できます。

  • ImageId, InstanceId, InstanceType, device, fstype, path: Disk
  • ImageId, InstanceId, InstanceType, cpu: CPU
  • ImageId, InstanceId, InstanceType, name: Disk I/O
  • ImageId, InstanceId, InstanceType: Memory

image.png

ImageId, InstanceId, InstanceType を選択すると、mem_user_percent および swap_user_percent の値を確認することができました。

image.png

アラームの設定

特に変わった手順はありません。
グラフ化したメトリクスからアクションのアラームの作成を選択します。
image.png

アラーム名、閾値、間隔、通知先等を任意に設定し、アラームの作成を押下します。
image.png

以上でメモリ使用率の監視設定が完了しました。
参考になれば幸いです。

続きを読む