aws memo

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

トップ > Ops

訳：クラウドのアプリケーションデザインパターン

AWS EC2 ELB 訳 Architecture Ops Develop

P.15からの、MTTRとMTTFを、従来のITとクラウドで比較検証するあたりがいい。

従来のITは、MTTFを長くすることに注力していたが、クラウドでは、MTTRを短くすることに注力できる。MTTFとMTTRがそれぞれ長い・短いでどうなるかを検証する。

P.17-P20 従来のITは、 MTTF,MTTRともに長い。クラウドは、MTTF,MTTRともに短いが、従来のITよりも可用性が向上している。最悪なのは、MTTFが短くMTTRが長いこと。

P.22 可用性向上のためには、レプリケーションとフェイルオーバーを組み合わせて使うが、フェイルオーバーは単純ではない。

P.28 SPOFを無くす方法。

  • 1. APサーバ1台でSPOFの状態
  • 2. EIPの付け替え
  • 3.LB配下に置く
  • 4.LBをさらに2重化する
  • 5.複数のAvailability Zone (AZ)に同じ構成を配置する
  • 6. ELB配下で複数のAZに置く
  • 7. さらにリージョンをまたいで冗長化する
  • 8. 他のクラウドとDNS等の仕組みで冗長化する

可用性を高めるベストプラクティスは、NetflixのChaos Monkey。MTTRを極限まで短くすることで可用性を高めている。

Ten^H^H^H Many Cloud App Design Patterns
View more PowerPoint from Shlomo Swidler

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

AWS EC2 Ruby Ops Develop fluentd

Fluentdは、Ruby1.9で動作するが、Amazon Linux 2012.03にプリインストールされているRubyは

ruby 1.8.7 (2011-12-28 patchlevel 357) [x86_64-linux]

となっている。ので、そのまま

sudo gem install fluentd

ではインストール出来ないので、事前にRuby1.9環境を用意する。

まずは開発環境

$ sudo yum install gcc make

次に、Ruby1.9 と、Ruby Gems1.9関連

$ sudo yum install ruby19 ruby19-devel rubygems19 rubygems19-devel rubygem19-rdoc

その後に、RDoc

$ sudo gem1.9 install rdoc

ここまでで下準備完了

ここからは、Gemでのインストール手順( Installation from RubyGems)に従う。

$ sudo gem1.9 install fluentd
$ which fluentd
/usr/local/bin/fluentd

fluentdのセットアップ

$ fluentd --setup /etc/fluentd
Installed /etc/fluentd/fluent.conf.

とりいそ起動

$ fluentd -c /etc/fluentd/fluent.conf -vv &

動作確認( Confirm installation )

$ echo '{"json":"message"}' | fluent-cat debug.test

あとは設定やら、よしなに。。。

AWS: 構成や利用状況をチェック、アドバイスするサービス Trusted Advisor report

AWS Architecture Ops

サポートの１サービスとして、Trusted Advisor report サービスというものがある。

http://aws.amazon.com/jp/premiumsupport/trustedadvisor/

 

サポートのサービスなので、旧体系ではGold/Platinum、新体系ではBusiness/Enterpriseが対象。

フォームで、アカウントID( xxxx-xxxx-xxxx-xxxx) を入力すると、以下のようなレポートが表示され、チェック結果と、問題があればその対処法が示される。結果はExcelファイルとしてもダウンロード可能。

 

f:id:understeer:20120620162203p:plain

チェックされる項目は大きく３つ

  • セキュリティチェック( ポート設定、CIDR設定、IAM設定）
  • フォールトトレランスチェック（スナップショット、ELB, Multi-AZ利用状況, etc)
  • コスト最適化チェック( 未使用EIP, 利用率の低いインスタンス)

構成変更のルーチンの中に、このチェックを入れておくと良いはず。

 

RDS: MySQLの管理者向けTips

AWS RDS Ops

RDSは、DBのroot権限をもらえないので、色々とRDS独自の代替手段(プロシージャ)が用意されている。

このあたりは要チェック。

Appendix: Common DBA Tasks for MySQL - Amazon Relational Database Service

めぼしいものをピックアップ

Slow Log ローテーション

mysql> CALL mysql.rds_rotate_slow_log;

セッションkill, クエリkill

mysql> mysql.rds_kill (thread-ID);
mysql> mysql.rds_kill_query (thread-ID);

レプリケーションスキップ

mysql> mysql.rds_skip_repl_error;

 他、MySQL5.1.62, 5.5.23には色々な情報を定期的に蓄積する Global Status History( GoSH)という機能があり、mysql.global_status_history テーブルに保存される。トラブルシュートに役立つことが期待されるが、デフォルトでは無効になっている。

GoSHを有効にする

mysql> CALL rds_enable_gsh_collector;

GoSHを無効にする

mysql> CALL rds_disable_gsh_collector;

GoSHの取得頻度を取得する

mysql> CALL rds_get_gsh_collector;

GoSHの取得頻度を設定する。デフォルトは5(分)

mysql> CALL rds_set_gsh_collector;

GoSHを即時で取得する

mysql> CALL rds_collect_global_status_history;

保存しているGoSH情報のローテーション間隔を設定する。デフォルトは7(日)

mysql> CALL rds_set_gsh_rotation;

保存しているGoSH情報のローテーションを有効にする

mysql> CALL rds_enable_gsh_rotation;

保存しているGoSH情報のローテーションを無効にする

mysql> CALL rds_disable_gsh_rotation;

保存しているGoSH情報を即時でローテーションする

mysql> CALL rds_drotate_global_status_history;

 

 

EC2: EC2 API Tools を Amazon Linuxにインストール

AWS EC2 Ops

Amazon EC2 API ToolsをAmazon Linuxにインストールする。

念のためインストール要件の確認

$ java -version
$ echo $JAVA_HOME

まずは、X.509　認証キーを作って、CERTファイルとプライベートキーファイルを取得しておく。（プライベートキーファイルは紛失しないこと）

Amazon Linuxにpemファイルをアップロードして、環境変数を設定する。

# pemファイル置き場を作成
$ mkdir ~/.ec2
# ~/.ec2 に、プライベートキーファイルpk-*.pemと、CERTファイルcert-*.pemを設置 
# その後、環境変数を設定
$ echo "export EC2_PRIVATE_KEY=~/.ec2/pk-xxxxxxxxxxxxxxxxx.pem" >> ~/.bashrc
$ echo "export EC2_CERT=~/.ec2/cert-xxxxxxxxxxxxxxxxx.pem" >> ~/.bashrc
$ source ~/.bashrc

次に、API Toolsをセットアップ

$ wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip
$ unzip ec2-api-tools.zip 
$ ln -s ec2-api-tools-1.x.x.x ~/ec2cli   # 2013.08.14 コメントでtypoをご指摘頂いたので修正
$ echo "export EC2_HOME=~/ec2cli" >> ~/.bashrc
# もともと/opt/awsにあるAPI TOOLSにパスが通っているのでそれより前に設定する
$ echo "export PATH=$EC2_HOME/bin:$PATH" >> ~/.bashrc 
# エンドポイントをTokyo リージョンにしておく
$ echo "export EC2_URL=https://ec2.ap-northeast-1.amazonaws.com" >> ~/.bashrc
$ source ~/.bashrc

動作確認

#リージョン一覧表示
$ ec2-describe-regions
REGION  eu-west-1       ec2.eu-west-1.amazonaws.com
REGION  sa-east-1       ec2.sa-east-1.amazonaws.com
REGION  us-east-1       ec2.us-east-1.amazonaws.com
REGION  ap-northeast-1  ec2.ap-northeast-1.amazonaws.com
REGION  us-west-2       ec2.us-west-2.amazonaws.com
REGION  us-west-1       ec2.us-west-1.amazonaws.com
REGION  ap-southeast-1  ec2.ap-southeast-1.amazonaws.com

インスタンス起動

$ ec2-run-instances ami-xxxxxx

インスタンス一覧

$ ec2-describe-instances

インスタンスstop

$ ec2-stop-instances i-xxxxx

インスタンスstart

$ ec2-stop-instances i-xxxxx

インスタンスTerminate

$ ec2-terminate-instances i-xxxxx

EC2: AWSからメールがくるケース

EC2 AWS RDS Ops

通常は関係ないが、稀にAWSから通知メールが来るケースがある（しかも英語）

よくあるメールの件名とその内容、および対策をメモ。

 

Amazon EC2 Maintenance - Network Connectivity Impact 

ネットワーク保守作業するから指定の時間帯ネットワーク切れるかもよ、との通知。ELB配下にあるインスタンスなら、指定された時間帯、ELBから切り離すか、新規インスタンスに作り変える。

Amazon EC2 Maintenance - Reboot Required 

仮想サーバホスト（物理サーバ）のパッチ適用等の理由で、指定期日までにインスタンスをrebootする必要があるよー、という通知。インスタンスリブートとシステムリブートの2種類がある（http://aws.amazon.com/jp/maintenance-help/）。インスタンスリブートを要求された場合は、該当インスタンスをOSレベルでrebootすればOK。　システムリブートを要求された場合は、インスタンスのstop/startでOK。

Notice: Amazon EC2 Instance scheduled for retirement

インスタンスに関する問題が発生しているため、指定期日までに速やかにStop/Startしてねー、という旨の通知。

＝＝＝

基本的には、メールと併用して、APIでスケジュールドイベントを監視しておくこと。

http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html

上記メールは、 Network maintenance, Instance reboot, System reboot, Instance retirementといったイベントとして取得・検知可能。

その他、ネットワークや電源メンテのスケジュールドイベントであるsystem-maintenance イベントが2012年5月に追加されている。

＝＝＝

ほか、RDS使ってると、メンテナンスウインドウで実施されるアップデートに伴いリブートが必要になる場合に通知が来る。

バックグラウンドで5億レコードをMySQLにロードする

RDS 訳 Ops AWS

Percona使うとかmy.cnf書き換え以外で、RDSでも使える部分があるか。

derwiki - Loading half a billion rows into MySQL

ポイントはこのへん

  • 外部キーチェック、ユニークチェックを無効にしておく
  • 分離レベルを、READ-UNCOMMITTEDにしておく
  • binlogを出さないようにしておく
  • innodb周りのconfigをチューニングしておく
  • データをチャンク分割してロードする