Best Practices in Evaluating Elastic Load Balancing : Articles & Tutorials : Amazon Web Services http://aws.amazon.com/articles/1636185810492479 ＝＝＝＝ 概要 ELBを最もよく評価するには、ELBのアーキテクチャを理解する必要がある。本稿は、AWS ELBの機能と独特なアーキテクチャについて述べる。ベストプラクティスを提供することで、ELBをテスト・評価する際に一般的な落とし穴(pitfall)から避けられるようになる。このホワイトペーパーが対象としている読者は、ELBの経験が少ないが、過去にH/W,S/Wのロードバランサを使ったことがあるような開発者である。 ELBの概要 ELBは、複数のEC2インスタンスへ、自動的にトラフィックを分散する。単
コンニチハ、千葉です。 AWSを利用していればcloud-initをご存知の方が多いと思います。ただ、「cloud.cfg上から説明して！」とか言われたら困ると思います。 なにせ、ぐぐってもあまり情報がありません。公式のドキュメントを読んでも設定方法やモジュール名は書いているのですがモジュールがデフォルトでどんな挙動するのか読み取れませんでした。なので、ソースコード(主にコメントw)頑張って読んでまとめました。 初期構築等で設定だけしたいのであれば、このページを見ればいけると思います。 cloud-initの実行タイミング ふわっと、初回起動みたいに覚えている方もいると思います。実際には初回起動以外にも実行タイミングがあります。 一生に？1回だけ実行されるもの インスタンスごとに実行されるもの(AMI作成し、そこからインスタンスを作成した時) 起動時に毎回実行されるもの ソースで、「fre
Route 53 に EC2 インスタンスの Public DNS を CNAME で登録して、それを EC2 インスタンス間での通信でも利用するという話です。 1. 前提 EC2-Classic 環境 EC2 インスタンスの接続情報（FQDN なり IP なり）は、AWS のメンテナンスによる再起動などで変更される。 アプリケーションやミドルウェアで、別インスタンスに接続している場合、AWS から割り当てられる Public DNS や IP を設定ファイルなどに記述していると、変更の度に修正が必要になる。 DNSサーバを立てようとしたが、そこまで変更の頻度は多くない（日常的にインスタンス数が増減するわけではない）ので、正直わざわざ立てるほどでも無い。また、DNS サーバの面倒も見たくない。 2. やりたいこと Route 53 で各ホストの接続情報を管理すれば、一元管理できるし、修正も
AWSにはコマンド経由でEC2のインスタンスに対する操作を行うことができます。 今回はWindows Server上にて、コマンドラインでEC2の設定を行ってみます。 まずは、以下のURLからAWSCLI64.msiをダウンロードします。 http://docs.aws.amazon.com/cli/latest/userguide/installing.html 上記のURLにはLinux上でaws-cliコマンドを使う方法も記載されているため、linux上でAWSをコマンド操作する際にも役に立つと思います。 aws-cliでコマンドを使うためには、 aws configureというコマンドで、設定を編集する必要があります。 $ aws configure AWS Access Key ID [None]: AKIAfJKJKVF AWS Secret Access Key [None]
特定のタイミングでシェルを動かしたい EC2インスタンスの起動や停止など、任意のタイミングで何か処理をしたいことがあるとおもいます。 例えば、次のようなケースです。 AutoScallingで起動されたインスタンスが、起動時にアプリケーションを起動したい terminate/stop予定のインスタンスが停止する前にデータのバックアップを行いたい Linux環境であれば、サービスとしてシェルスクリプトを登録することで、インスタンスの起動や停止時に処理を行うことができます。 使用した環境 EC2のOS : Amazon Linux やってみる 起動時/停止時実行されるシェルを作成 まずはインスタンス起動/停止時に実行されるシェルを作成します。 下記のような、起動/停止時にメッセージを特定のファイルに出力するだけの単純なシェルを作成します。 名前は、「mytest」とでもしておきましょう。 なお
12/1からクリスマスまで、1人ずつリレー形式でブログ記事を書く AWS Advent Calendar 2012 の20日目です。 去年・一昨年は、WordPres Advent Calendar 2011、PHP Advent Calendar 2010 に参加しましたが、今年は AWS Advent Calendar に参加します。 さて EC2 インスタンスに EIP (固定IP)を設定して運用するケースって多いと思うんですよ。 しかし EC2 のインスタンスでは、一度停止した後再起動すると EIP が外れてしまいます。 一時的にスケールアップしたくて、インスタンス停止して再起動とかいうオペレーションは、まま有ると思います。 その時に EIP を associate し忘れて「あら、サイトに繋がらないわ」なんてうっかりミスをすることも多いと思います。 そんな、うっかりさんのために
また一段と寒くなりました。 2月には雪かもしれませんね。 弊社でもチラホラと体調を崩す人が増えてきました（俺含む）。 風邪って奴に完全な抵抗力を持つ日は来るのでしょうか… さて、本日はちょいとサーバサイドのお話。 コンピュータの負荷指標は色々ありますが、皆様はどれを重要指標としてますでしょうか。 前にも少し触れましたが僕が気にしている指標を一応列挙いたします。 ELBのLatency EC2のCPU Usage EC2のMemory USAGE (-/+ buffers/cacheのused) EC2のCPU LoadAverage RDSのCPU Usage RDSのDBConnect I/O周りでは、 EC2のSwap I/O EC2のDisk I/O RDSのDisk I/O と言った感じです。 これらをCloudWatchで毎分観測し、物によってはAlert設定をしています。 今回
ども、大瀧です。 EC2からEメールを送るという案件、たくさんありますよね。そして結構な確率でトラブるんですよね(涙目)。そんな苦い経験をベストプラクティスとしてまとめてみました。一応技術的なところは網羅したつもりですが、メールセキュリティの専門ではないので、不備や間違いがあればご指摘ください。 では、メール送信トラブルの元凶である、スパムメールとその対策からご紹介していきます。 スパムメールとの闘いダイジェスト Eメールの歴史は、スパムメールとの闘いの歴史と言えます。 不特定多数に送信されるスパムメール(未承諾の広告メール)は、メール受信者に不快な思いをさせるとともに、メールサーバーのメール流量を爆発的に増加させ、長らくメールサーバー管理者を泣かせてきました。 このスパムメールをなんとか撃退しようと、現在では主に以下のような対策が行われています。 1. 送信メールサーバー側のネットワーク
こんにちは。小椋です。 「まあ15分ぐらいなら落ちてても実際そこまで困らないけど、基本的には24時間起動していてほしいんだよね……」 という緩めのサービスレベルで稼働しているSPOF気味なサーバー、ありますよね。社内向けのジョブスケジューラーとか、一日に数回なんか集めて分析する奴とか。あんまり表立って言わないだけで、御社にもありますよね？ サービスレベルが緩めだし、ミッションクリティカルでもないので、ただ起動しっぱなしにしてほっとけばいいや……と思いきや、やっぱり止まったら止まったで処置も必要だし、生死確認はちゃんとしないといけないし、そもそも起動しっぱなしなのでお金もかかるし、とか、意外とお金も労力もかかりますよね。 私HDEの社長ですが、サーバ代に関してはかなりケチです！ そういうケースに関しては、場合によってはEC2のAutoScaling Groupで管理すると節約ついでに横着でき
2015 - 12 - 21 Amazon EC2 Container Service(ECS)と戯れた1年とコンテナ芸人の来年について Docker AWS ECS この記事は Container with AWS Advent Calendar 2015 の21日目の記事です。 昨日は pottava さんの「 AWS で docker-swarm クラスタ を立ち上げようとして失敗した話」でした。 qiita.com Amazon EC2 Container Service (ECS)と戯れた1年 今年はproductionにDockerを投入するという、自分としてはかなりアプリケーションの アーキテクチャ に変革が起きた年だったので振り返ってみようと思います。んで、来年の戦略等をば。 書いた記事 書いた記事はこんな感じ。 stormcat.hatenablog.com ameblo
はじめに 皆さん、User-Dataを使っていますか？複数のEC2に同様の設定を適用してLaunchしたい時には便利な機能です。 このUser-Dataにはシェルスクリプトを直接書くか、あるいはcloud-init形式で記載することが出来ます。これは1行目が"#!"で始まっていればシェルスクリプト、"#cloud-config"で始まっていればcloud-init形式として処理されます。なおAmazon Linuxに導入されているcloud-initは元々のcloud-initをカスタマイズしたものであり、独自拡張がされていたり、一部のディレクティブが使えなかったりするので注意が必要です。 今回、このcloud-initを使った初期設定を色々と調べたので、まとめてみました。 Tips 設定及びログの確認 repo_update, repo_upgrade yum_repos package
前回の記事で EC2 と RDS によるミニマムなサーバー環境の構築手順をご紹介しました。 この環境はアプリケーション・サーバーがユーザー (Internet) からの HTTP リクエストを受け付けるだけでなく、管理者によるサーバーメンテナンスのための SSH 接続も受け付けるという構成になっています。AWS 再入門ということで、最初のお勉強としてはこれでも上出来かと思いますが、いくらミニマム構成とはいえ、これをこのまま本番運用するとなるとセキュリティの観点からイマイチよろしくありません。 ではどうするのが良いのか？ そもそもアプリサーバー自体が外部から直接 SSH 接続を受け付けること自体よろしくありません。外部からのSSH接続は、アプリサーバーとは別の専用サーバーが受け付けるべきです。そしてそのサーバーからアプリサーバーにSSH接続するといった二段階接続の構えをするというわけです。し
AmazonLinuxのECインスタンス起動時、cloud-initによりホスト名を[Nameタグ_インスタンスID_IPアドレス]に設定するメモになります。 EC2インスタンスを複数作成する場合、各インスタンスのホスト名にNameタグやインスタンスIDを付けて、操作対象のインスタンスを見分けやすくしたいといった事があるかと思います。EC2インスタンス起動時にホスト名を[Nameタグ_インスタンスID_IPアドレス]として設定するようにしたいと思います。 ■概要 EC2インスタンス内の/var/lib/cloud/scripts/per-boot/配下にスクリプトを作成し、EC2インスタンスに設定しているTagsやmetadataからインスタンスIDやNameタグ等を取得し、EC2インスタンス起動の度、ホスト名を[Nameタグ_インスタンスID_IPアドレス]に設定します。 ■EC2インス
はじめに AWSで、外部からのアクセスを遮断、あるいは外部へのアクセスを制限することを目的に、外部への通信経路を持たないプライベートサブネットを作成するパターンがあります。この場合プライベートサブネットに配置したインスタンスは外部へ一切通信が出来ないため、ミドルウェアのアップデートや外部サービスとの通信などは、外部アクセスが可能なパブリックサブネットに配置したNATインスタンスを経由するように設計します。 しかし、場合によっては通信元のインスタンスによって、外部に接続する際の接続元のグローバルIPアドレスを切り替えたい場合があります。例えば外部サービスにて接続元グローバルIPアドレスにより振り分けを行っていて、接続元グローバルIPアドレスが全て同じだと正常動作しない場合などです。 この「NATインスタンスで、通信元インスタンスによって、接続元のグローバルIPアドレスを切り替えたい」というw
どうも、セクションナインの 吉田真吾（@yoshidashingo）です。 さきほどAWSからこんな発表がありました。 New – Managed NAT (Network Address Translation) Gateway for AWS | AWS News Blog Amazon VPCにNAT Gateway機能が追加されたそうなのでさっそく以下のような構成で試してみました。 VPC構成 VPC 10.0.0.0/16 Subnet 1: 10.0.0.0/20 Route Table 1 10.0.0.0/16 local 0.0.0.0/0 NAT Gateway Subnet 2: 10.0.16.0/20 Route Table 2 10.0.0.0/16 local 0.0.0.0/0 Internet Gateway 1. VPCとサブネットを作成する こんな感じ
【新機能】ついに登場！Amazon VPC NAT GatewayでNATがAWSマネージドに | DevelopersIO
こんにちは、せーのです。 今日はついに登場した新サービス「Amazon VPC NAT Gateway」をご紹介します。 AmazonマネージドのNATが登場 今までプライベートなサブネットに立ててあるEC2インスタンスからインターネットに出るにはパブリックなサブネット上に自分でNATインスタンスを立てる必要がありました。 NATが落ちるとプライベートにあるEC2群からは一切インターネットに出ることができなくなるのでNATは冗長化して複数構成にするのが常でした。その結果そんなに使うわけでもないNAT用のEC2インスタンスを最低でも2台立て、しかもこのNATがパフォーマンスのネックにならないようにとある程度大きめのインスタンスタイプを選ばざるを得ないこともあり、コストが大変かかるものでした。 NATが落ちた時の切替も自分でスクリプトを組んで行っていましたが完全なものではありませんでした。 今
はじめに AWSにはRDSというマネージドなデータベースサービスがあることは皆さんご存知だと思います。そこで提供されているデータベースは、MySQL、Oracle、SQLServerの3種類です。そうです、PostgreSQLが無いのです！ナイナイ詐欺のAWSなので、そのうち出てくると思いますが、今のところはありませんので、自前で構築する必要があります。せっかく構築するなら、オンプレのコピー感覚で使うのではなく、クラウドネイティブに使いたいものです。今回は、そんなPostgreSQLをEC2上で構築するために考えるポイントをまとめたホワイトペーパーをベースに理解を深めたいと思います。 PostgreSQL on Amazon EC2 PostgreSQLは、ACID(Atomicity:原子性, Consistency:一貫性, Isolation:独立性, Durability:永続性)
Amazon VPCでELBとNATを使ってよりセキュアな環境を作る【5日目】 | DevelopersIO
公開するサーバはセキュリティを特に強化する ELBを介してEC2インスタンスのWebアプリにアクセスするとき、ELB以外からのアクセスを拒否したくなります。また、公開IPアドレス自体も持ちたくありません。公開IPを持たせたくないということでVPCを前提に考えます。そして、ELBをパブリックサブネットに置いて、EC2をプライベートサブネットにすることで実現できます。今回は、VPCを使ってELBとNATインスタンスを使ったセキュアな環境を構築したいと思います。 VPCとELB ELBとAutoScalingが連携できることは知られていますが、VPC内でも使うことができます。 VPC内のELBのテクニックとして、ELB自体をパブリックサブネットに置いてEC2をプライベートサブネットにおくことがあります。ELBがリバースプロキシとして働いて、EC2はELBからのHTTPインバウンドのみ受け付けるの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
