AWS活用セミナー「AWSの利用を躊躇されている方々へ」
2015年10月23日にアイティメディア主催**「主導権はユーザー側が持つ 企業のためのAWS徹底活用セミナー」**に登壇いたしました。 当日セミナーにお越しいただけなかった方にもお伝えできるよう本ブログにてコンテンツとしてお届けいたします。 セミナー概要 AWSの利用を躊躇されている方々へ 株式会社ISAO infra R&D プロジェクトリーダー 片貝 力也 本日はAWSの利用を躊躇している方々に向けて、利用当初の注意点や問題になりやすい事項を簡単に紹介させて頂きます。具体的な実例をもとにご説明させて頂きたいと思いますが、既に利用いただいている方々にとっては物足りない内容になってしまいます。その点、予めご了承ください。また最近ニーズが高まっているAWSでのセキュリティ対策についてもご紹介いたします。 EC2以外のサービスを利用しますか？ AWS（Amazon Web Searvices）を利用される予定の方々に質問です。 EC2以外のサービスを利用しますか？ もちろんEBSやELB、S3なども利用しないとサービスとして成り立たないかと思いますが、現状AWSにて構築を検討する際に、まずAWSで提供しているマネージド込みのサービスをどこまで使用するかが一つの重要なポイントになります。EC2上に自前でミドルウェア環境を構築していくのか、RDSやElastiCashなどミドルウェアまで揃えているマネージドサービスを利用するのか、どこまで利用するのか一度検討ください。ただマネージドサービスを利用することで構築の手間が大幅に省けますし、運用の手間も簡略化されるため、工数が減りコスト減にも繋がりますので、利用される事を通常お勧めします。 しかし、1点気を付けなければならないのがベンダーロックイン（※）状態です。 数年毎に別のシステムへの移設を検討しなければならない場合は、マネージドサービスを利用していると移設検討が非常に困難となってしまいます。ただAWS環境から他環境への移設メリットは無い、もしくは薄いケースが殆どだと思いますので、現状ですとマネージドのサービスを躊躇せずに利用して問題ないと思います。またAWS環境にて安定的なサービス運用をする為にもマネージドのサービスを利用する事は近道となります。 （※）ベンダーロックイン 特定の環境・技術に固定され、他との互換性が損なわれるとこと ただシステム環境以外にも構築運用メンバーの技術スキルもAWSに踏襲・専属化していってしまいますので、昨今のインフラメンバーでは、オンプレミス環境のネットワーク設計や導入作業が出来ないといった事態も発生してます。 インフラエンジニアを抱えていらっしゃる企業様は、運用リソースの配置や今後のスキルパスまで考えていくことが必要です。 AWSの月額費用って本当に安いの？ AWS利用で発生する月額費用は、規模がある程度大きくなると決して安くは見えません。 特にオンプレミスで構築した場合のCPUのコア数やハードウェアのパフォーマンス等を、そのまま踏襲してAWSで試算をすると、1年や複数年のスパンでハウジング費用と比較すると高くなるケースが多々あります。ただし、これは単純に発生する月額費用を比較した場合の話なので、実際は見えにくい運用でのコストを加えて比較すべき内容です。 AWSは構築運用だけでなく、設計や管理、オンサイト作業のコストを除外できることも大きなメリットとなります。 例えばデーターセンターに行く必要がないというのが分かりやすい一例です。それらを計算に入れると正しいAWS費用の試算ができます。 またインスタンスの稼働を100%ではなく、実負荷を想定した変動性でコスト試算できるとよりメリットが見やすくなります。 リザーブドインスタンスって？ さらに、AWSにはリザーブドインスタンス（RI）という年間契約でお安くなるプランもございます。 このRIは1年もしくは3年契約での割引サービスだけでなく、「リザーブド」の名前が示すようにインスタンスの起動が約束されます。 契約しているとインスタンスの数が確保でき、稀にある「リソースが枯渇していて必要なインスタンスの数が上がらない」といった心配も無くなります。 インスタンスの起動に失敗した場合、数分〜数十分待ってから起動させる必要があるのですが、RIは契約分のリソースが確保される事になります。 手動でオペレーションしている場合は大きな問題にはなりませんが、規模が大きくなり自動化等を取り入れていると、スムーズなインスタンスの起動は重要な課題となります。 AWSのメンテナンスってどうなの？ EC2のメンテナンスには主に2種類あります。 アップデート用メンテナンス リタイアメント用メンテナンス 1つ目はAWSが実施するセキュリティアップデートです。こちらは特定のタイミングを指定し、AWS側が実施するメンテナンスとなります。なので環境や対象によっては、そのタイミングでサービスを停止、メンテナンスに切り替える必要があります。ただライブマイグレーション等で対応できる範囲も増えているようなので、今後は年に1回あるかどうかだと考えてます。 2つ目はハードウェア故障やリタイアメントによる、インスタンスのstop/startとなります。こちらは取り扱いインスタンス台数が増えるにつて対象となる可能性も高まりますので、わたくしの感覚ですと1,000台程度起動していると毎週どこかで発生する程度の頻度となります。ただこちらは指定された日までの好きなタイミングでstop/startをすれば良いだけなので、通常サービスへのインパクトはそれほど高くなりません。※ただ通常平日の4:00からとかに実施しますので、作業者が頻度によっては少々大変になります。 またインフォメーションは英文メールでとどきますので、見逃さないように注意が必要です。 Eventとしてもマネージドコンソールで確認できますので、弊社はAPI経由でEvent監視をしてアラート発報させてます。 上限緩和申請って知っていますか？ 意外に知られていないのですが、AWSには非常に多くの起動数や設定数の上限設定がなされています。 EC2インスタンスの起動数やEBSのトータルボリューム数、ELBの数、SecurityGroupの数等、それは多岐にわたります。 例えば、EC2インスタンスはタイプにもよりますが、20がデフォルトの起動上限数です。 よって、21以上のインスタンスを起動したい場合は、事前にマネージメントコンソールから上限緩和申請をする必要があります。 この上限緩和は少し時間を要しますので、構築作業の前日までには申請をしておいた方が無難です。...zabbixのグラフで日本語が文字化けを直す
おはようございます。インフラ宮下です。 zabbixのグラフ設定は標準では日本語が表示されません。 ※アイテム名に日本語を使っている場合です。 動作環境はこんな感じです。 OS：CentOS release 6.5 (Final) バージョン：zabbix-server-2.2.3 「監視データ」→「グラフ」で作成したグラフを見てみると下記のように日本語の部分が□になってしまいます。 これはアイテムに日本語を使っていて画像変換時にフォントがないのが原因です。 まずはフォントがおかれている場所を確認します。 # ls /usr/share/zabbix/fonts/ graphfont.ttf 次にOSに搭載されているフォントを確認します。 $ ls /usr/share/fonts/ dejavu ipa-gothic ipa-mincho ipa-pgothic ipa-pmincho vlgothic IPAを使います。ただシンボリックリンクを張るだけでOKです。 特にzabbix-serverの再起動も必要ないです。 # ln -s /usr/share/fonts/ipa-pgothic/ipagp.ttf /usr/share/zabbix/fonts/ipagp.ttf # vi /usr/share/zabbix/include/defines.inc.php （変更箇所） 7 39c39 < define('ZBX_GRAPH_FONT_NAME', 'ipagp'); // font file name --- > define('ZBX_GRAPH_FONT_NAME', 'graphfont'); // font file name 86c86 < define('ZBX_FONT_NAME', 'ipagp'); --- > define('ZBX_FONT_NAME', 'graphfont'); このようにグラフもきちんと日本語表示されました。...【AWS】CloudWatchを使ってEC2インスタンスのリソース状況を確認する
はじめまして、ディレクターの白川です。 AWSではGUIから様々なサービスが利用出来るので、ディレクター職の自分にも非常に優しくていいですね。 さて、Webサービスを運用していくためには、インフラの稼働状況を監視することが必要不可欠です。 機器自体の死活監視に加え、メモリやCPU、ディスクなどのリソース使用状況を常にモニタリングし、負荷状況に応じて適切な対応を行わなければなりません。 そこで今回は、AWSが提供するクラウド監視ツール、CloudWatchを利用してEC2インスタンスのリソース使用状況を確認する方法についてご紹介します。 １．CloudWatchの確認方法 AWSマネージメントコンソールにアクセスし、メニューの中からCloudWatchを選択します。 画面左の「Dashboard」の中から、[EC2]を選択します。 インスタンス毎のIDとメトリクス名が表示されます。グラフを表示したいインスタンスとメトリクスの組み合わせを確認し、チェックボックスにチェックを入れます。 画面下にグラフが表示されます。 ※図はCPU使用率を表示したイメージです。 ２．グラフの見方 [Average]というドロップダウンボックスが、各データの集計方式(Statistics)を指します。 それぞれ、平均(Average)、最小値(Minimum)、最大値(Maximum)、合計(Sum)が選択出来ます。 ※データサンプル数(Data Samples)は、サンプルとして取得したデータの数になります。こちらは、CPUやメモリなどの使用状況を確認する上ではあまり使用しないかと思います。 ３．CloudWatchで確認出来る、EC2の標準メトリクス CloudWatch上で確認出来るEC2のメトリクスなどは、下記のAWSドキュメントを確認ください。 参考： AWSドキュメンテーション「Amazon EC2 メトリックスを表示する」 ４．まとめ CloudWatchでは、今回ご紹介したEC2のリソース以外にも、RDSやELB、Auto Scalingなど様々なAWSリソースの監視が可能です。 ただし、CloudWatchの統計は2週間しか保存されないため、長期的なスパンでのリソース分析には向きません。 そういった場合は、Zabbixなどの高機能な監視ソフトウェアの利用を検討する必要があります。 ISAOでも、Zabbix等を利用した高レベルなクラウド監視実績が多数ありますので、ご検討の際は是非ともお声掛けください。...Chefで既存手順のレシピを書く５（munin、zabbix）
おつかれさまです。小宮です。 前回に引き続き、munin,zabbixの手順のレシピをご紹介します。レシピはこの記事でおしまいです。 記事の最後にはレシピの適用方法を記載します。 ・muninのレシピ # cd /opt/src/rpms # mkdir -p /root/chef-repo/site-cookbooks/munin/files/default/rpms # mkdir -p /root/chef-repo/site-cookbooks/munin/files/default/var/www/html/munin # mkdir /root/chef-repo/site-cookbooks/munin/files/default/etc/munin/plugin-conf.d # cp -p /etc/munin/munin.conf /root/chef-repo/site-cookbooks/munin/files/default/etc/munin/ # scp -Cp ｘｘｘ-web01:/etc/munin/munin-node.conf /root/chef-repo/site-cookbooks/munin/files/default/etc/munin/ # cp -p /var/www/html/munin/.htaccess /root/chef-repo/site-cookbooks/munin/files/default/var/www/html/munin/ # cp -p /etc/munin/plugin-conf.d/munin-node /root/chef-repo/site-cookbooks/munin/files/default/etc/munin/plugin-conf.d/ # tar cf /root/chef-repo/site-cookbooks/munin/files/default/rpms/munin-node-rpm.tar ./munin-node-rpm/ # tar tf /root/chef-repo/site-cookbooks/munin/files/default/rpms/munin-node-rpm.tar ./munin-node-rpm/ # tar cf /root/chef-repo/site-cookbooks/munin/files/default/rpms/munin-serv-rpm....