aws memo

AWS関連の備忘録 (※本ブログの内容は個人的見解であり、所属組織及び企業の意見を代弁するものではありません。1年以上古いエントリは疑ってかかってください)

AWS: 管理系サービス (SaaS) まとめ

色々出てきているので、備忘を兼ねて。

コメントはメモ書き程度の感想なので、詳細は各ページを見に行く。気がついたら追加する予定。

 

Cloud Management by RightScale

定番。マルチクラウドの管理も可能。

 

enStratius in header

こちらも定番。自動化とかが便利かも。

scalr cloud management software

自動化、スケジュール、マルチクラウド、Chefサポート等。

 

Cloudworks クラウドワークス -AWSを乗りこなす

日本製なので、日本語UIで使える。

 

(Skeddly)  自動化的なやつ。

 

色々できるかんじ。よく調べてないw

GUIでAWSの構成が組めるかんじ。

定番。Security Groupのチェックや、ムダなインスタンス・EIPのチェックなども。モバイルアプリも便利。

 

 

クラウド管理、構成、デプロイ、モニタリング

クラウド管理、構成、モニタリング

クラウド管理、構成

こちらも定番ぽい。

コスト監視。アラート通知など。

 CloudCheckr

リソースの分析、チェック、コスト監視

 

性能監視、リソースの利用状況分析、デプロイ

 cloudhealth-logo-medium

 

リソースモニタリング、複数のAWSアカウントを集約統合できるぽい

CloudAlly backup your online data

バックアップ機能

メモ: PinterestとInstagramのAWS利用状況

PinterestもInstagramも成長スピードがものすごい。

Pinterest

AWS SUMMIT NY 2012 のKeyNote中にあったPinterestのパートが記事になっている

Pinterest growth driven by Amazon cloud scalability - Techworld.com

High Scalability - High Scalability - A Short on the Pinterest Stack for Handling 3+ Million Users

Polyglot persistence at Pinterest: Redis, Membase, MySQL • myNoSQL

Pinterest Architecture Numbers • myNoSQL

High Scalability - High Scalability - Pinterest Architecture Update - 18 Million Visitors, 10x Growth,12 Employees, 410 TB of Data

High Scalability - High Scalability - A Short on the Pinterest Stack for Handling 3+ Million Users

Pinterestの急成長を支えてきたアーキテクチャとは? Pythonで開発しAmazonクラウドで運用 - Publickey

Revealed: Inside super-soaraway Pinterest's virtual data centre • The Register

AWS SUMMIT NY 2012 のビデオの12:30から23:10の間

 

Instagram

What Powers Instagram: Hundreds of Instances, Dozens of Technologies - Instagram Engineering

「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか - Publickey

EC2: スケジュールイベントでリタイア通知

EC2インスタンスを使っていると、稀に、EC2インスタンスを動かしている物理マシンのメンテンナンスが必要になる場合に遭遇する。メンテナンスイベントには何種類かあり、Instance reboot、System reboot、 Instance retirement などがある。詳しくはマニュアルを参照のこと。

Monitoring Events for Your Instances - Amazon Elastic Compute Cloud

AWSブログにも説明がある。

【AWS発表】 EC2インスタンスのステータスモニタリング - Amazon Web Services ブログ

イベントに該当した場合は、通知のメールで「何月何日の何時頃にシャットダウンするよ」と言われるので、それまでにインスタンスを stop & start するとよい。

Stopping and Starting Instances - Amazon Elastic Compute Cloud

通知のメールはこんなかんじ

Subject: Amazon EC2 Instance scheduled for retirement [AWS Account: 123456789ABC]
From: Amazon EC2 Notification 

Dear Amazon EC2 Customer,

One or more of your Amazon EC2 instances in the ap-northeast-1 region is scheduled for retirement. The following instance(s) will be shut down after 12:00 AM UTC on 2012-08-28.

  i-xxxxxx

We recommend that you launch a replacement for each retiring instance and begin migrating to it. You can do this by stopping and re-starting your instance, or by terminating it and launching a new one in its place.

マネジメントコンソール上はこんな感じで時計のマークが一覧に表示され、Scheduled Event の項目にも表示される。

 

f:id:understeer:20120827104807p:plain

Eventの項目にも、Scheduled Event対象のインスタンスが表示され、その期限などが表示される。

f:id:understeer:20120827104818p:plain

 

ec2-describe-instance-status のコマンド or APIでも取得可能なので、外部の監視ツールと組み合わせて定期的に監視しておき、retiringになったら通知する仕組みを用意しておくのも良い。

 

リーンスタートアップとDevOps

ビジネスとシステムという少し距離のある2つだが、共通点が非常に多いし、ゴールは実は同じという点で、リーンスタートアップとDevOpsを組み合わせることは非常に効果的だろう。

つまり、常に計測可能な数字をもって仮説とし、それを測定する仕組みも必ず一緒に組み入れその結果を検証し次のサイクルを回す。素早いサイクルで回すには、DevOps(特に自動化)は欠かせない要素になるし、ビジネスサイドとシステムサイド(とくにDevelopmentとOperation)が協業する文化が一番大事になってくる、ということ。

Devops and The Lean Startup | Agile Zone

===

リーンスタートアップは、我々が顧客に本当に意味のあることに注力すべきである、と説いている。データに基づいた試みを短いサイクルでまわす科学的な手法を使うことを進めている。しかし、自社ビジネスのすべての領域を網羅して試みを継続的に行うには、全社の協力が必要になる。まさに、DevOpsのゴールの一つとされている、クロスファンクションなチームが必要である。リーンスタートアップとDevOpsの考えがどのように相互作用して、製品開発フローを成功に導くかを見てみよう。

データ駆動試験

リーンスタートアップの手法では、新機能に対するビジネス的な評価軸に対する明確な仮説を立てることで、製品開発を開始する。もしホームページに”購読”ボタンを加えようとするなら、まず最初に期待値を明確化する(例えば「購読率は0.5%である」)。仮説が用意できたら、どのように結果を計測するかを考える。DevOpsの強みでもある、何をどのように計測するか?を知ることがアイディアの初期段階である。また、データに基づいた試験として機能開発を進めることは、早期に社内でフィードバックを得ることになる。

DevOps : 協業の文化

DevOpsは、クロスファンクションチームの全メンバー間で協業する文化である。開発フローの運用サイドから発生したDevOpsは、すべてのフローを最適化することを狙っている。そしてDevOpsは、できる限り速く顧客について知るための試験を実行する際に必要となることでもある。引き継ぎや遅延といったすべての無駄は、顧客について学ぶスピードを遅くし、そして邪魔をする。

すごい力を組み合わせる

革新的な製品を作ろうとしているなら、できる限りの助けを使うべきだ。リーンスタートアップのテクニックを適用することで、本当に価値のあるものを確実に作れるだろう。 DevOpsの文化を取り入れることで、クロスファンクションチーム全体が、フィードバック・ループに入ることができる。素早く製品を見直す( "rinse & repeat")なら、自動化を使うことでそのスピードを早くすることができる。そして、製品の変更が現実のビジネスに与えた影響の測定ができるようになる。これが、あたなと、あなたの顧客にとっての、成功のためのキーである。

Amazon Linux用の Zabbix RPMを作る

Amazon Linuxで Zabbix 2.0系を動かすには、現状はソースからコンパイルが必要。@kodai74 さんが公開している RHEL/CentOS用RPMだと、libmysqlclient.soの依存関係で怒られる(Amazon Linuxだと新しすぎるorz)。

てことで、RPMを自前で作っておいて、ばら撒く作戦。

参考にしたのはこのお二人

TNKの気になること: Zabbix 2.0をAmazon Linux上で動かしてみよう

zabbix2.0をAmazonlinuxにインストールしたった。(rpm) - zabbiたんAMIたん

==以下、上記ブログからコマンドラインだけ抜粋==

$ cd
$ sudo yum install git
$ git clone https://github.com/atanaka7/zabbix-jp-amzn1.git
$ sudo yum -y install rpm-build
$ sudo yum -y groupinstall 'Development tools'
$ sudo yum -y install mysql-devel net-snmp-devel openldap-devel sqlite-devel unixODBC-devel libssh2-devel java-devel curl-devel OpenIPMI-devel postgresql-devel
$ sudo yum -y install php-cli php-mbstring php-common php-mysql php-xml php-pdo php-gd php-bcmath php
$ wget http://www.zabbix.jp/binaries/relatedpkgs/rhel6/x86_64/fping-2.4b2-16.el6.JP.x86_64.rpm
$ wget http://www.zabbix.jp/binaries/relatedpkgs/rhel6/x86_64/iksemel-1.4-2.el6.JP.x86_64.rpm
$ wget http://www.zabbix.jp/binaries/relatedpkgs/rhel6/x86_64/iksemel-devel-1.4-2.el6.JP.x86_64.rpm
$ sudo yum -y localinstall *.rpm
$ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
$ cat <<EOS > ~/.rpmmacros
%_topdir /home/ec2-user/rpmbuild
%_builddir %{_topdir}/BUILD
%_rpmdir %{_topdir}/RPMS
%_sourcedir %{_topdir}/SOURCES
%_specdir %{_topdir}/SPECS
%_srcrpmdir %{_topdir}/SRPMS
EOS
$ rpmbuild --rebuild ~/zabbix-jp-amzn1/zabbix-2.0.0-1.amzn1.src.rpm
$ mkdir ~/zabbix-rpm
$ cp ~/rpmbuild/RPMS/noarch/*.rpm ~/zabbix-rpm
$ cp ~/rpmbuild/RPMS/x86_64/*.rpm ~/zabbix-rpm

S3: Amazon Linuxにs3cmdをインストールしてコマンドラインでS3を操作する

S3は、まずは Management ConsoleやCloud Berry ExplorerCyberDuckといったGUIツールから使うか、 AWS SDK for PHP, Java, Ruby, .NET といったAPI経由で使うことが多い。(参考:S3の関連ツール・ライブラリ等 - aws memo )

バックアップ処理など、cronなどでスクリプトから操作したい場合は、s3cmdが便利。

インストール

Amazon Linuxでデフォルト無効になっている epelリポジトリからインストール

$ sudo yum -y --enablerepo epel install s3cmd

もしくは、ここからyumのリポジトリファイルを取得して、/etc/yum.conf.d/にコピーした後にyum installする。

$ wget http://s3tools.org/repo/RHEL_6/s3tools.repo ~/
$ sudo cp s3tools.repo /etc/yum.conf.d/
$ sudo yum -y install s3cmd

設定

コンフィグウィザードを起動し ~/.s3cfg を作成。ウィザードで最低限必要なのは、Access KeyとSecret Key。残りはデフォルトのままリターンでOK。あとから .s3cfgを編集可能。

$ s3cmd --configure
Access Key: xxxx
Secret Key: xxxx

実行例

バケツ一覧

$ s3cmd ls

リージョンを指定してバケツ作成

$ s3cmd mb --bucket-location=ap-northeast-1 s3://<bucket_name> 

バケツにアップロード

$ s3cmd put -r /path/to/files s3://<bucket_name>
# --acl-public オプションをつけると、アップロードと同時にweb公開
$ s3cmd put --acl-public -r /path/to/files s3://<bucket_name>

 バケツ内オブジェクトのパーミッションを変更しWeb公開

$ s3cmd setacl  -r --acl-public s3://<bucket_name>

バケツの使用量確認

$ s3cmd du s3://<bucket_name>

バケツへの差分同期

$ s3cmd sync /path/to/source/dir s3://<bucket_name>/prefix
$ s3cmd sync s3://<bucket_name>/prefix /path/to/source/dir 

バケツ間のコピー

$ s3cmd cp  s3://<source_bucket_name>/object s3://<dist_bucket_name>/

Amazon Linux でApacheのログを Fluentd経由でMongoDBに集約する

10genからこんな記事が

The 10gen Blog on MongoDB and NoSQL, Fluentd + MongoDB: The Easiest Way to Log Your Data Effectively.

 ===

ということで、Amazon Linuxでの環境構築メモ

まずは、httpd+Fluentdを入れるインスタンス (web)と、MongoDBを入れるインスタンス(mongo)を用意して、インストール。

EC2: AMazon Linux にFluentdをインストール - aws memo

EC2: AmazonLinuxにMongoDBをインストール - aws memo

次に、fluent-plugin-mongo をインストール

$ sudo /usr/local/bin/fluent-gem install fluent-plugin-mongo

その後、上記URLにあるように、fluentdがapacheのaccess_logをtailして見るようにsouceを定義し、その内容をmongoに送信するように matchを定義する

$ sudo vi /etc/fluentd/fluent.conf
$ sudo cat /etc/fluentd/fluent.conf
--snip--
<source>
   type tail
   format apache
   path /var/log/httpd/access_log
   tag mongo.apache
</source>
<match mongo.apache>
   type mongo
   database apache
   collection access
   host mongo.example.com
   port 27017
   #interval
   flush_interval 10s
   #capped
   #capped_size 100m
   #user test
   #password testpass
</match>
--snip--

 あとは、mongoサーバのSecurity Groupで27017を適宜空けておき、httpd+fluentdサーバで、fluentdを起動してから、おもむろにブラウザでアクセスして access_logにログを書き込ませる。

mongo側では

$ mongo
> use apache
> db.access.find()
> db.access.find().count()
> db.access.find({code : "200" })
> db.access.find({code : "200" }).count()

等で確認できる。