1 Minute Tips

カテゴリー: tech

  • Amazon Rekognition Video について

    あまり馴染みのないサービスの一つ Amazon Rekognition Video について調べた。

    Amazon Rekognition Video は ライブビデオストリーミング をリアルタイムで解析して、顔を検出し、判別することができる。

    ユースケース

    • Amazon Kinesis Video Streams のストリーミングデータの処理
      Rekognition Video に入力し、最大数千万もの顔データと照らし合わせて、超低レイテンシーでの顔認識を行うことができる。
    • バッチ処理
      Amazon Rekognition Video では Amazon S3 に保存した録画データを解析することもできる。

    アクセス方法


    Amazon Rekognition には、Amazon Rekognition API、AWS マネジメントコンソール、および AWS コマンドラインインターフェイス (CLI) を使用してアクセスすることが可能。

    コンソール、API、CLI では、Rekognition API を使用して、ラベル検出、顔分析、顔照合、顔検索を行える。

    利用方法

    AWS Lambda には Rekognition 用の設計図が用意されている。

    それを使うことで s3 や DynamoDB といった AWS データストアでのイベントに基づいて画像分析をすることができる。

    Amazon Rekognition Videoは、Amazon Kinesis Video Streamsを使用してビデオストリームを受信および処理する。

    分析結果の利用方法

    分析結果は、Amazon Rekognition VideoからKinesisデータストリームに出力され、クライアントアプリケーションによって読み取られる。

    Amazon Rekognition Videoは、ストリーミングビデオの分析を開始および管理するために使用できるストリームプロセッサ（CreateStreamProcessor）を提供する。 

    分析結果はKinesis Data Streams Consumerに読み取られる。（Kinesis Data Streams Analyticsではない）

    また、本題とは異なるが、以下のサービスについて補足

    Amazon Kinesis

    リアルタイムのストリーミングデータを簡単に収集、処理、分析できる。

    コスト効率よくストリーミングデータを処理するための重要な機能を提供。

    設定としては、Kinesis Agent を設定してデータを収集し、

    Amazon Kinesis Data Firehoseを使用してエンドツーエンドのデータ配信ストリームを作成する。

    その上で、

    Amazon Kinesis Data Analytics で SQL クエリを使用してリアルタイム分析を実施することができる。

    Amazon Kinesis Data Streams

    Amazon Kinesis Data Streams によって処理されたレコードはダッシュボードに送信されて、さまざまなAWSサービスへのデータ送信に使用できる。

    分析するアクションとして、アプリケーション側にAmazon Kinesis Client Library（KCL）ワーカーを組み込んで行動分析を実施することができる。

    また、Amazon Kinesis Data Streamsアプリケーションは、Amazon Kinesisストリームからデータをデータレコードとして読み取る。

    これらのアプリケーションはAmazon Kinesis Client Library（KCL）を使用することでAmazon EC2インスタンスで実行するデータ分析アプリケーションを作成することができる。

    Amazon Kinesis Data Analytics

    Amazon Kinesis Data Analytics は、ストリーミングデータの分析に利用するサービス。Amazon Kinesis Data Analytics を利用すると、ストリーミングアプリケーションを構築し、管理し、AWS のサービスと統合する作業がシンプルになる。

    Amazon Kinesis Data Analyticsを利用して、ストリーミングアプリケーションを構築し、管理し、AWS のサービスと統合する作業が実施できる。

    SQL クエリを使用してリアルタイム分析を実施することができる。

  • s3のファイルのバージョニングを有効化した際の挙動

    s3 のバージョン管理を有効した場合の振る舞いについて整理する。

    そもそもバージョニングとは、同じバケット内でオブジェクトの複数のバージョンを保持する手段。

    バージョニングを使用して、Amazon S3 バケットに格納されたあらゆるオブジェクトのあらゆるバージョンを、格納、取得、復元することができるようになる。

    バージョニングを使用すれば、アプリケーション障害からも、簡単に復旧でき流。

    S3バージョン管理を有効にすると、既存のファイルはすべて、バージョンIDがNULLになる。

    バージョン管理後に追加されると、そのファイルの バージョンIDは ランダム値が割り振られる。

    公式ドキュメントは以下の通り

    https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/Versioning.html

  • s3内の特定ファイルを特定の国に対して利用できないようにする際に考えること

    以下の２つの要件を満たしたい時がある

    • 特定の国に対して利用できないようにしたい。
    • コンテンツを世界中のユーザーに低レイテンシーで配信したい。

    CloudFront ウェブディストリビューションを活用する。

    https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/DownloadDistS3AndCustomOrigins.html

    CloudFront ウェブディストリビューションを使うことで配信しているコンテンツに対し特定地域のユーザーによるアクセスを回避することができる。地域制限を使用するには、次の 2 つの方法が考えられる。

    ・CloudFront の地理制限機能の使用
    エッジロケーションによる地理的制限を有効化。

    ディストリビューションに関連するすべてのファイルへのアクセスを制限し、国レベルでアクセスを制限する場合は、この方法を使用する。 

    これをすると、S3 の公開しているバケットの中のファイル全てに制限をかけることができる。特定のファイルにのみ制限をかけることはできない。

    ・サードパーティの位置情報サービスの使用

    上記 CloudFront の地理制限機能を使って要件を満たすことができない場合は、サードパーティのツールを探すことになる。

    なお、Lambda＠エッジを利用した制限アルゴリズムを連携するといった機能は現状存在しない。

  • VPC内インスタンスからインターネットに対して特定ドメイン以外のアウトバウンド接続を拒否する際に考えること

    ネットワークACLはURLに基​​づいてリクエストをフィルター処理できない。

    プロキシサーバーを利用して制御することで回避が可能。

    プロキシサーバーはクライアントからの要求をフィルターし、製品の更新に関連する要求のみを許可するため、製品の更新以外のすべての要求のフィルターすることができる。

    プロキシサーバーとは、内部ネットワークのセキュリティを損なわずにネットワークの外部と接続できるようにする、LAN 上のコンピューターを指す。

    プロキシサーバーは内部コンピューターのアイデンティティを保護するために一般的に使用される。

    プロキシサーバーは、内部ユーザーおよびサーバーからの要求の仲介役として機能して、多くの場合はコンテンツをキャッシュして後続の要求を高速化する。

    AWSではVPNまたはAWS Direct Connect接続を使用して既存の企業プロキシサーバーインフラストラクチャを活用したり、内部ELBを備えたSquidプロキシサーバーなどのソフトウェアを使用してAWSでフォワードプロキシファームを構築したりすることが一般的なユースケースになる。

  • Vimでよく使う便利なコマンド

    Vimでよく使う便利なコマンド

    検索文字をハイライトする

    :set hlsearch!

    オートインデント

    :set autoindent

    行番号を表示

    :set nu

  • CloudWatch Logsで任意の文字列を監視してグラフ化する

    CloudWatch Logsで任意の文字列を監視してグラフ化する

    概要

    シェルでラップして見たい値をCloudWatchに飛ばして監視する。

    今回はその仕組みを流用してサーバのプロセス数を監視監視した。

    ディレクトリ作成

    どこでも良い。今回はec2-userの下にcloudwatchディレクトリを作成する

    mkdir /home/ec2-user/cloudwatch
cd /home/ec2-user/cloudwatch

    シェル作成

    vi CustomMetrix.sh

    #!/bin/sh
CUR_DIR=/home/ec2-user/cloudwatch

export JAVA_HOME=/usr/lib/jvm/jre
export AWS_CLOUDWATCH_HOME=/opt/aws/apitools/mon
export EC2_REGION=ap-northeast-1
export AWS_CREDENTIAL_FILE=${CUR_DIR}/credential
InstanceId=`cat /var/tmp/aws-mon/instance-id`
# 設定ファイル
PROCESSCONFIG=${CUR_DIR}/process-conf.txt

# Process Check(設定したファイルから読み込む)
cat ${PROCESSCONFIG} | sed '/^$/d' | grep -v '^#.*' | while read PROCESS
do
COUNT=`ps aux | grep ${PROCESS} | grep -v grep | wc -l`
echo ${PROCESS}:${COUNT}
/opt/aws/bin/mon-put-data --metric-name ${PROCESS} --namespace "CustomMetrix" --dimensions "InstanceId=${InstanceId}" --value ${COUNT}
done

# LoadAverage(1分間の測定値を取得)
/opt/aws/bin/mon-put-data --metric-name "LoadAverage" --namespace "CustomMetrix" --dimensions "InstanceId=${InstanceId}" --value `cat /proc/loadavg | awk '{print $1;}'`

    設定ファイル

    process-conf.txt

    httpd
crond

    認証情報

    credential

    AWSAccessKeyId=aaaaaaaa
AWSSecretKey=ccccccccc

    実行

    sh ./CustomMetrix.sh

    httpd:0
crond:1

    結果

  • GitLab Connection to gitlab.com timed out. (connect timeout=5)’))

    GitLab Connection to gitlab.com timed out. (connect timeout=5)’))

    はじめに

    GitLabに接続する際、

    GitLab Connection to gitlab.com timed out. (connect timeout=5)'))

    のように表示されることがある

    原因

    接続元が同しIPの接続元から、gitLabに複数回アクセスしたものの認証に失敗した。

    しかし、なんどもログイン失敗したため、接続元のIPを自動でプラックリストに入ってしまったことが原因

  • Baseimage-dockerとは

    Baseimage-dockerとは

    docker は 1コンテナ 1プロセスで動かすという思想のもと作られているが、普通のコンテナ思想のもと作られたコンテナではない。

    ssh でログインすることもできるし、 cron も動かすこともできる。

    supervisorなどのプロセスコントロールシステムを使えば複数プロセス起動させることもできるので、この仕組みを使っているちょっと変わった 80M 程度の軽量なコンテナだ。

    利用方法は以下の通り。まずは pull

    docker pull phusion/baseimage:master

    起動

    docker run --rm -it phusion/baseimage:master

    Baseimage-dockerのiniプログラムが実行される。

    ctrl + cで抜ける事ができる

    この ini 処理で supervisor が動き、そのプロセスの中で ssh を受け付けたり, cron を動かしたりしている。

    Debug方法

    Baseimage-dockerのiniプログラムを実行させず、直接bashを起動は以下の通り

    直接コンテナに入ることができる。

    docker run --rm -it phusion/baseimage:master bash -l
  • Alternative Directory LayoutでAnsible-playbookを作った際に考えたこと

    Alternative Directory LayoutでAnsible-playbookを作った際に考えたこと

    はじめに

    Ansibleで環境を作ろうと思えば、Ansibleのディレクトリ構成をどのような作り方もできてしまうが、Ansibleのbest practicesのAlternative Directory Layout (https://docs.ansible.com/ansible/2.5/user_guide/playbooks_best_practices.html#alternative-directory-layout )を元に構成を作ることにした

     

    なぜAlternative Directory Layoutか

    まず、Alternativeではない、正攻法(?)のDirectry Layoutは、以下のとおり

    Directry Layout

     

    これに対し、Alternative Directory Layout は Staging/Production が 明確に分かれているのが特徴だ

    Alternative Directory Layout

    双方のメリット・デメリット

    メリット

    productionとstagingがディレクトリが分かれているため 環境ごとに設定を変える事ができる。

    Directry Layoutの場合、productionとstagingがディレクトリが分かれていない。

    そのため、productionとstagingが全く同じ環境であればよいが、ランニングコストを下げるためにStagingのみ台数を減らしたり、パラメータを変更するようなことが柔軟にやりにくくなってしまう。現在のみならず、先々を考慮しこの構成を採用した

    デメリット

    ほとんどの設定ファイルがproductionとstagingで冗長してしまう

    結論

    上記デメリットがあるものの、Alternative Directory Layout を採用することによる享受できるメリットが判断し、このレイアウトを採用することにした。

  • error pulling image configuration: Get https://xxxx : net/http: TLS handshake timeout

    error pulling image configuration: Get https://xxxx : net/http: TLS handshake timeout

    はじめに

    docker pullした際、以下のような TLS handshake timeout が発生

    # docker pull koda/docker-knowledge
Using default tag: latest
Trying to pull repository docker.io/koda/docker-knowledge ... 
latest: Pulling from docker.io/koda/docker-knowledge
55cbf04beb70: Pulling fs layer 
1607093a898c: Pulling fs layer 
9a8ea045c926: Pulling fs layer 
1290813abd9d: Waiting 
8a6b982ad6d7: Waiting 
abb029e68402: Waiting 
8cd067dc06dc: Waiting 
1b9ce2097b98: Waiting 
d6db5874b692: Waiting 
25b4aa3d52c5: Waiting 
53ec227dabf0: Waiting 
242938ace8b4: Waiting 
85bc5aaf4ec5: Waiting 
fd5b749ebe99: Waiting 
6636846685ec: Waiting 
error pulling image configuration: Get https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sha256/9a/9ae2dde61ad6947df46e2cc416be9249f314d187feb717f6e18c0dc9a46bf5bf/data?verify=1538549397-3vZspNti03KIKxRXPmQsQeUbucI%3D: net/http: TLS handshake timeout
#

    解決方法

    docker login

    # docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: 
Password: 
Login Succeeded
#
    一度ログインすると、その後取得が可能になる
    # docker pull koda/docker-knowledge
Using default tag: latest
Trying to pull repository docker.io/koda/docker-knowledge ... 
latest: Pulling from docker.io/koda/docker-knowledge
55cbf04beb70: Pull complete 
1607093a898c: Pull complete 
9a8ea045c926: Pull complete 
1290813abd9d: Pull complete 
8a6b982ad6d7: Pull complete 
abb029e68402: Pull complete 
8cd067dc06dc: Extracting 7.242 MB/122.1 MB
1b9ce2097b98: Download complete 
d6db5874b692: Download complete 
25b4aa3d52c5: Download complete 
53ec227dabf0: Download complete 
242938ace8b4: Download complete 
85bc5aaf4ec5: Download complete 
fd5b749ebe99: Download complete 
6636846685ec: Download complete