はてなブックマーク

先日、AWSソリューションアーキテクト アソシエイトレベルを受験してきました。 なんとか合格できたので、その勉強方法などをご紹介したいと思います。 試験までにやったこと その1「実際に利用する」 何よりもまず「AWSを実際に使ってみる」ことが一番大切だと思います。 AWSは、１つのサービスだけでも、たくさんの機能があります。 どこをどのように設定するとどうなるのか、自分で色々使ってみて覚えていくのが合格に一番近道だと感じました。 その2「Eラーニング」 APNパートナーになっているとAWS公式のEラーニングを受講できます。(無料です) エンジニア向け、営業向けなどのコースがあり、それぞれ5つくらいのトレーニングが用意されています。 また、各トレーニングに対応した「評価テスト」を受けることができます。 評価テストとは、各トレーニングの内容を理解度をチェックできる確認テストです。 個人的には、

前回は、AWSのRDSサービスでのリードレプリカ機能についてご紹介しましたが、今回も同じくRDSサービス(ここではAmazon RDS for MySQLのみが対象)のログ機能に関するソリューションをご紹介します。 さてこのログ機能、Parameter Groupsにて設定することでスロークエリログやジェネラルログを取得することが可能となるのですが、少々癖のある仕様となっており、主に以下のような点が挙げられます。 WEBブラウザ上でいちいち見なければいけない 一時間ごとにローテートされる 1時間でローテートされ、24時間しか保持されないため、数日前のログが見たい時に詰む 1時間でファイルが切れるので、調査しづらい こういった不便により、「もうEC2上でMySQL動かしちゃえばいいや」と判断した方がいらっしゃるのではないでしょうか。 ログ至上主義、CUI至上主義の私にとってはこれがいささか不

今回は簡単にできるWordPressのセキュリティ設定を紹介します。 「簡単に」ということで、方針を以下のとおりとします。 方針：ソースは変更せずに簡単に。 WordPress本体やプラグイン、利用テーマのコードは変更しません。 WordPress自体のコードを修正するとアップデート等に支障が出る可能性があります。 プラグインやテーマのコードの変更は、コンテンツへの影響があるので、今回は対象外とします。 この方針の中で、今回実施する内容は次の5点です。 wp-admin/wp-login.phpへのアクセス制限 wp-config.phpへのアクセス制限 ログインパスワードを複雑にする readme.htmlを削除する テーマやプラグイン利用のポリシーを決める では、1番目からです。 1.wp-admin / wp-login.phpへのアクセス制限 wp-adminディレクトリ以下は管理

負荷テストは、インフラ環境をサイジングするうえでの具体的なデータを与えてくれます。この記事では、インフラ事業者視点で負荷テストについての目的、種類、実施方法について考えてみます。 ※面倒な準備は無しで、簡単に負荷テストを実施したい人向けに、WEBインタフェースから負荷テストがおこなえるシステムを作成中です。 インフラ事業者から見た、負荷テストの目的 サイジングの妥当性を証明できる インフラ事業者から見た場合、負荷テストの最大のメリットはサイジングの妥当性を証明できることです。 当社も提案の際に、サイジングに必要な情報を確認していきます。月間の（想定）アクセス数、ピーク時の（想定）アクセス数、平均ページサイズ、リプレイスであれば各サーバのCPUやメモリ、ディスクなどのリソース情報などです。しかしながら、具体的な情報がでてくることは多くありません。そのため、想定しているアクセス数やシステムの内

ドイツリージョンの開設が昨日発表されました。 AWS発表(Now Open - AWS Germany (Frankfurt) Region) そこで、以前調べたのと同じ方法で、ドイツリージョンと東京リージョンの距離とレイテンシを調べてみました。 準備 まずはドイツリージョンでサーバを立てて、Apacheをインストールしておきます。 コマンドプロンプトの反応はモッサリしていて、プロンプトが返ってくるのが東京リージョンに比べて、ワンテンポ遅れる感じです。 計測 次に、東京リージョンのサーバから次のコマンドで、ドイツリージョンのサーバに対して、HTTPのレスポンスタイムを計測します。 $ curl -kL 'http://XXX.XXX.XXX.XXX/' -o /dev/null -w "%{http_code}\t%{time_total}" 2> /dev/null 200 0.563

AWSには、とっても便利なオンラインストレージの「S3」というものがあります。 これをシステムに組み込んで利用することで、更に便利に使うことができます。 その為の方法はいくつかありますが、一つの方法として、サーバのコマンドラインから操作するという方法があります。 コマンドライン操作で、よく知られているものに「s3cmd」というツールがあります。 文字通り、S3の各種機能をコマンドラインから操作できるものです。 導入はとても簡単です。 例えば、CentOSでは、epelレポジトリを使えば、yumコマンドで簡単にインストールが可能です。 しかし、epelからインストールできるs3cmdはバージョンが古く、「1.0.1」のものがインストールされます。 実際に、デフォルト状態のCentOS上で確認すると、 # yum info –enablerepo=epel s3cmd Name : s3cmd

概要 先日より話題になっているbashの脆弱性[Shell Shock]ですが、RHEL5とCentOS5では、最新バージョンにアップデートしてもbashのバージョンが違います。 本来なら、RHELとCentOSは互換性がある為、パッケージのバージョンは同じになるので、今回のアップデートでも同じバージョンになるはずです。 しかし、なぜか下記のように、最新状態にアップデートしてもバージョンが微妙に異なります。 RHEL5 bash-3.2-33.el5_11.4 CentOS5 bash-3.2-33.el5_10.4 ちなみにRHEL6とCentOS6では、同じバージョンになります。 これは、RHEL5とCentOS5のOS自体のバージョンのズレによるものと思われます。 2014年9月29日現在で、RHEL5の最新バージョンは「5.11」でCentOS5の最新バージョンは「5.10」です。

今回は、流行りのDockerコンテナを管理するツールである「Panamax」をインストールして、Sensu環境を簡単に構築してみます。 Panamaxとは Dockerは簡単にサーバを構築できますが、複数のコンテナを連携させるマルチコンテナな環境を作るのは、すこし手間がかかる部分がありました。 そこで、Panamaxを使って、マルチコンテナをWebインターフェースで簡単に構築する環境を作ってみようと思います。 Panamaxインストール環境 Panamaxは、MacやUbuntuなど、いくつかの環境にインストールできます。 Windowsの場合は、Cygwinを使ってインストールする方法が紹介されています。 Githubリンク：「Installing Panamax」 いくつか試してみましたが、今回は一番簡単だった「AWS上のCoreOS」にインストールしようと思います。 構成イメージ 作

AWSを始めとしたクラウドサービスを会社で使っていると、マネージメントコンソールの操作に対して、ユーザ毎に利用できる機能を制限したり、アクセスできるIPアドレスなどを制限したいという要件が出てくることがあると思います。 AWSのIAMという機能を使うと、そういったことを簡単に細かく設定することができますので、今回はその紹介です。 今回は要件例として、以下の内容でポリシーを作ってみます。 特定アカウントに対して、権限をEC2とRoute53の参照権限のみにする。 特定のIPアドレスからのみアクセス可能IPにする。 では、早速見ていきます。 ユーザの作成 まずは、AWSコンソールにログインし、IAMの画面で「Users」をクリックします。 「Users」の画面で、「Create New Users」をクリックします。 次に、作成するユーザ名(testuser)を入力して、「Create」をクリ