CapistranoでAWS EC2インスタンスをデプロイする時の注意点
前回のデプロイ設定ファイルで新たに作成されたEC2インスタンスには、キーペアやセキュリティグループなどが設定されていなかったため、そのままでは作成したインスタンスにSSHでアクセスできませんでした…1orz その後、色々とデプロイ設定を修正して、作成したEC2インスタンスにSSHでログインするところまで出来たので、その経緯を備忘録として書いてみた次第。 まぁ、CapistranoでAWSのEC2インスタンスを作成する際…というより、「AWS SDK for Ruby」でEC2インスタンスを作成する時の注意点…に近いのかもしれない。 まず、前回のconfig/deploy.rbからインスタンスラウンチのタスク部分を見てみる。 desc 'Launch an EC2 instance to each availability zone different' task :launch do run_locally do ec2 = AWS::EC2.new created_instances = [] cnt = 0 while cnt < fetch(:instance_count) do if cnt.even? then current_az = fetch(:availability_zones)[0] current_sn = fetch(:subnet_ids)[0] else current_az = fetch(:availability_zones)[1] current_sn = fetch(:subnet_ids)[1] end i = ec2....PV InstanceからHVM Instanceへ変換(CentOS6)
準備するもの ① EC2 Instance(CentOS6)既存の動いているものでもOK ② 変換元のRoot deviceのSnapshot ③ ②から作成したEBS Volume (SSDのほうが作業が早い) ③ 空のEBS Volume (SSDのほうが作業が早い) DEVICEの確認 # fdisk -l |grep dev Disk /dev/xvda: 10.7 GB, 10737418240 bytes Disk /dev/xvdb: 4289 MB, 4289200128 bytes Disk /dev/xvdf: 10.7 GB, 10737418240 bytes <-PV環境のRoot device Disk /dev/xvdg: 10.7 GB, 10737418240 bytes <-空のEBS Volume 作業開始 １．PVのDiskを縮小し、コピー容量を減らす...Capistranoで異なるAvilabilityZoneにEC2インスタンスをラウンチする
前回、 次回はデータベースの作成や初期設定を直前タスクとして挿入して、さらにWordPressの設定ファイルの書き換え、GitHubからWordPressテーマをダウンロードするところまでやってみようと思います。 とか云っていたのですが、都合によりCapistrano3を使ってAWSのEC2インスタンス作成を行ったので、そのTIPSを残しておこうかと思います。 今回は、デプロイ用のEC2インスタンスから公式のAMIを利用してAvailabilityZonesが異なるエリアにそれぞれEC2インスタンスを立ててみました。試験的に、AMIは最新のインスタンスタイプ「t2.micro」に対応した「Amazon Linux AMI 2014.03.2 (HVM)」を利用して、Tokyoリージョンの1aと1cのAvailabilityZoneにそれぞれ2台ずつ、合計4インスタンスを同時に立ててみます。 ※ 事前準備として、インスタンスを立てるAWSアカウントにてVPCやSubnet等EC2インスタンスを作成する上で必要最小限の設定をしておく必要があります。特に今回は異なるAvailabilityZoneへのインスタンスを立てるのでそれぞれのゾーンにSubnetを設定しておく必要があります。 さて、早速デプロイの手順です。 はじめに、デプロイ環境（サーバ）の設定を行うため、config/deploy/test.rbを編集します。 今回は動的に作成したEC2インスタンスをデプロイ環境とするため、事前のサーバ設定ができません。というのも、AWSで立ち上がる新規インスタンスにはElasticIPを付与しないので、毎回PublicIPが異なり、エンドポイントURLも動的に変わってしまうためです。なので、今回はインスタンスが起動した後にCapistoranoのタスクにて対象サーバを設定するようにします。 初期のサーバ設定は不要となるので、記述をコメントアウトしておきます。なお、SSHのオプションだけは最終的に共通で利用する予定なので残しておきます（今回のデプロイタスクでは使いませんが…）。 $ vim config/deploy/test.rb #role :app, %w{deploy@localhost} #role :web, %w{deploy@localhost} #role :db, %w{deploy@localhost} set :ssh_options, { keys: %w(/home/deploy/.ssh/id_rsa), forward_agent: true, } 今回のデプロイでは、「AWS SDK for Ruby」を利用するので、あらかじめSDKをインストールしておきます。 $ sudo gem install aws-sdk 次に、config/deploy.rbにデプロイ内容を設定します。 $ vim config/deploy.rb # config valid only for Capistrano 3....AWS認定ソリューションアーキテクト–アソシエイトレベル受験体験記
おはようございます。インフラの宮下です。 ゴールデンウィーク突入の直前に「AWS 認定ソリューションアーキテクト – アソシエイトレベル」を受験しましたので、 試験の手続き方法や勉強内容について守秘義務に反しない程度にご紹介します。 ○ 試験の事、そして申込みまで 試験範囲は、Blueprintが公開されていますので正確な情報はそちらを確認してください。 blueprint 現時点での出題配分は下記の通りで、Blueprintでは一つ一つ細かく説明がなされています。 時間の限られている社会人は、勉強の基本はBlueprintを見て戦略を練るのが最短距離とい言うのが私の方針です。 1.0 Designing highly available, cost efficient, fault tolerant, scalable systems 60% 2.0 Implementation/Deployment 10% 3.0 Data Security 20% 4.0 Troubleshooting 10% Blueprintを一読した印象では、単純にサービスを知っているだけでは厳しそう、という印象でした。 実際に試験を申し込まないと受験できませんので、申込方法を説明します。 AWSのページで案内している通りKryterion社が試験を提供しています。 ここでの注意点は、英語ページのままサインアップすると試験が英語版しか出てきません。 サイトが日本語ページである事を確認してサインアップしましょう。（英語版を希望する時は逆に英語でサインアップする） サインアップ後に「試験のお申し込み」で「AWS 認定ソリューションアーキテクト-アソシエイトレベル」を選択すると 試験会場の選択そして日時の選択になります。 私は、池袋の会場で申し込みました。池袋の地理に明るい自分はすぐに分かりましたが、不慣れな人は 場所はしっかりと確認しておいた方が良いかもしれません。 大塚方面を線路沿いに進み、公園の向かい向かいにあるそんなに大きくないビルの中になります。 試験日程ですが、まだ会場がそれほど多くないせいか直近1週間は結構混んでいます。 1～2週間先をゆとりをもって予約をするのが良いと思います。 試験を申し込んだら完了メールが来ますので、印刷して当日は必ず持参しましょう。 結構大事な事がかいてあります。 「受験者認証コード」を提示しないと受験できなかったり、身分証明書を2種類用意するとか ○ 試験対策について...CloudFormationを使いredmineのインスタンスを起動する
おはようございます。インフラの宮下です。 社内向けredmineが古いのでリプレイスを検討しています。 できるだけ手間をかけずに検証環境を用意したいと思い、AWSのcloudformationを使って redmineを用意してみました。 目次 はじめに CloudFormationでインスタンスを作成する インスタンスが起動してからの設定 はじめに 現在稼働しているredmine環境が物理サーバにバージョンがRedmine 1.1.2.stable (MySQL)ととても古いので最終的には入替まで実施したいと思います。 CloudFormationでインスタンスを作成する ManagementConsoleからCloudformationの画面を開きます。 「Create Stack」で新規作成を開始します。 ・Name→管理しやすい名前を自由につける。 ・Template→Use sample templateの中のSingleInstanceSamplesの中から「Redmine Project Management System」を選ぶ。 ※検証環境なので今回は最小化された構成で構築します 「Next Step」で次に進みます。 Specify Parametersにそれぞれ値を入れていくのですが、デフォルトではkeyを指定する事ができませんでした。 という事で一旦「Back」で戻ります。 amazonが公開している下記のテンプレートをローカルPCに保存します。 https://s3.amazonaws.com/cloudformation-templates-us-east-1/Redmine_Single_Instance.template サンプルとの違いは、KeyNameの定義が入っているだけですのでSSHログインしないというのであれば この作業は不要です。 [shell]（8行目） “KeyName”: { “Description” : “Name of an existing EC2 KeyPair to enable SSH access to the instances”, “Type”: “String”, “MinLength”: “1”, “MaxLength”: “255”, “AllowedPattern” : “[\\x20-\\x7E]*”, “ConstraintDescription” : “can contain only ASCII characters....GitHubでpush時にAWS OpsWorksで自動デプロイする方法
開発の平形です。 今日は、GitHubでpush時にAWS OpsWorksで自動デプロイする方法をお教えします。 OpsWorksはAWSで提供されているデプロイのサービスです。 ＊OpsWorksについては、こちらのサイトが詳しいです。 この話は、OpsWorksにスタックとレイヤとインスタンスが存在する前提です。 OpsWorks自体、最近触ったばかりですが、 デプロイがすごく簡単にできるという事はよくわかりました。 でも、欲張りな僕は、もっと自動化できないのかな？と思ったのです。 普段、ソースはGitHubでバージョン管理しているので、 GitHubにpushしたら同時にデプロイできないのかな？と。 そしたら、ビックリするほど簡単に実現できました。 GitHub側で設定が可能です。 アプリケーションのリポジトリのページの「Settings」 「Service Hooks」 AWS OpsWorks 以下の項目は全て必須なので、全部入力します。 ここで、OpsWorks側の情報が必要になります。 まずは、Stack Idですが、一見これがわかるところが、AWS Managed Consoleの画面上にはありません。 手っ取り早くこれを確認する方法はStackの画面のURLをみる事です。 次にApp Idですが、同じくOpsWorksの画面で、「Apps」=>「アプリケーション名」をクリック OpsWorks IDがApp Idです。 Branch Nameはリポジトリのデプロイしたいブランチ名を指定。 AWSのアクセスキーとシークレットキーを入力し、Update settingsをポチっとします。 あとは、該当ブランチにpushするだけ！ これで自動的にOpsWorksのデプロイが走ります。 僕はこれに感動しました！ ただ、欲張りな僕はまたまた思ったのですね。 OpsWorksではスタックを本番環境とステージング環境と分けて運用してるとします。 そうすると、 releaseブランチはステージング masterブランチは本番 にそれぞれ自動デプロイできたらいいなー、と。 しかし、一つのリポジトリにつき、一つのスタックの設定しかできないんですよね。 という事で「できない」という事がわかり、取り乱しました。 まあ実際の運用で、masterのpushしただけでいきなりデプロイするのもトラブルの元になりそうだし、 そういうもんなんだ。って自分に言い聞かせて落ち着きを取り戻しました。 それでも便利には変わりないですけど。 あなたのデプロイライフがもっと充実しますように。 以上、平形がお届けしました。...MysqlのHAとトラブル事例
久しぶりの更新になります。プラットフォームの宮下です。 先日開催されました、July Tech Festa2013というイベントの中の1コマで何と私が発表をさせて頂きました。 その時使用した資料をアップしますので興味のある方は是非一読下さい。 [slideshare id=24320385&doc=mysqlha-130716215401-phpapp02] mysqlのHA構成のデザインパターン紹介を経験談を交えて話させて頂きました。 とても緊張してしまって肝心のトラブル事例がお話出来ませんでした。このブログでは、包み隠さずトラブルのレポートが出来ればと思います。 今回のテーマは、小宮先生のレポートを多分に活用させて頂いています。 次回こそは、私の成果を発表したいもんです。 それではまた近いうちに更新します。...mysqlパフォーマンス改善への道（その1、現状の確認）
パワー不足のmysqlをチューニングしてみます。 こんばんわ。プラットフォーム担当の宮下です。 今回は、バックアップ兼集計用に稼働しているmysqlのレプリケーションンサーバの パフォーマンス改善していきたいと思います。 これまでにもいくつか対策はしてきましたが、まずは環境をおさらいします。 ◇稼働してる環境は、AWSのEC2でlargeインスタンスを使用しています。 サービスは、OpenPNEを使用したSNSのサービスとなります。対象のMysqlはバックアップとデータ集計が目的で稼働しています。 （本番サービスでは使用していません） ◇mysqlのバージョンはちょっと古くて「5.0.77」になっています。multiで起動させていていて この他に開発環境用のmysqlも稼働していたりします。 ちなみに今の遅延秒数は、「1512561 秒」でまだ増加中です。 ◇これまでに変更した点ですが、 「innodb_buffer_pool_size」を512Mから2028Mまで増加、 「innodb_flush_log_at_trx_commit」を2から0に変更、 （リカバリの精度よりもスループットを優先） 「key_buffer_size」を32Mから300Mに変更、 「query_cache_size = 0」にして無効化しました。 効果は、DISKのI/Oが半分くらい減りましたが、遅延解消とまではいってません。 ◇最後にmuninで取得しているデータを確認します。 遅延が日々増えています。たまに減る事もありますが要因は分かりません。 常にDISKのread I/Oが大量に発生しています。 原因ははっきりしていて、DBデータに画像や動画データが格納されている為となります。 buffer pool sizeでは収まり切らないデータサイズなので常にDISKのread/writeが発生しています。 またMyISAMとInnodbが混在していてリソースが効率的に利用出来ていない事や、 OpenPNEが「delete aaa filename LIKE ‘%bbb%’」というクエリを大量に発行している事 などが解決すべき課題がたくさんあります。 現状を整理した事で、次回からは一つずつ改善対策を実施していきたいと思います。...AmazonEBSでraid0を組んだ時のパフォーマンス検証
AmazonEBSでraid0を組んだ時のパフォーマンス検証 EBSを組むと早いはなしを検証したい testでマルチ、ラージなら結構こうかある説がある模様。 既存移行の方法も検討(バイナリログ等のディレクトリ分けるところからかと。) 公式のユーザガイド（EBSPerformance） EBS自体が冗長構成組まれているのでraid0でいいと思われる。 インスタンスディスク（ローカルディスク、エフェメラルディスク）を使ってRAID0 EBSでRAID0を組むことは、RAID10(ミラーのストライプ）と同等である Largeインスタンス以上であれば、1台よりも2台の方がディスクI/O性能が目に見えて上がりました エフェメラルディスク(stopすると消えるほうのディスク)でraid0したい場合の起動コマンド例 [shell] ec2-run-instances ami-e965ba80 –region us-east-1 –key id_rsa –group sg-a4866fcc –placement-group test –instance-type cc2.8xlarge -b “/dev/sdb=ephemeral0” - b “/dev/sdc=ephemeral1” -b “/dev/sdd=ephemeral2” “/dev/sdf=ephemeral3” [/shell] ・ラージでEBSディスクを2つ追加して起動してログインする [shell] # df -h Filesystem Size Used Avail Use% Mounted on /dev/xvde1 9.9G 867M 8.5G 10% / none 3....