AWS: 管理系サービス (SaaS) まとめ
色々出てきているので、備忘を兼ねて。
コメントはメモ書き程度の感想なので、詳細は各ページを見に行く。気がついたら追加する予定。
定番。マルチクラウドの管理も可能。
こちらも定番。自動化とかが便利かも。
自動化、スケジュール、マルチクラウド、Chefサポート等。
日本製なので、日本語UIで使える。
(Skeddly) 自動化的なやつ。
色々できるかんじ。よく調べてないw
GUIでAWSの構成が組めるかんじ。
定番。Security Groupのチェックや、ムダなインスタンス・EIPのチェックなども。モバイルアプリも便利。
クラウド管理、構成、デプロイ、モニタリング
クラウド管理、構成、モニタリング
クラウド管理、構成
こちらも定番ぽい。
コスト監視。アラート通知など。
リソースの分析、チェック、コスト監視
性能監視、リソースの利用状況分析、デプロイ
リソースモニタリング、複数のAWSアカウントを集約統合できるぽい
バックアップ機能
メモ: PinterestとInstagramのAWS利用状況
PinterestもInstagramも成長スピードがものすごい。
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 - 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の間
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 の項目にも表示される。
Eventの項目にも、Scheduled Event対象のインスタンスが表示され、その期限などが表示される。
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 Explorer、CyberDuckといった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からこんな記事が
===
ということで、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()
等で確認できる。