先日、EBS(Elastic Block Store)のとある状況下での挙動について正確なところが知りたくて、改めて調べていました。その中で、AWSマイスターシリーズ ReloadedのEBS版を見つけたのですが、これが良い資料でした。今までEBSのネットワーク部分についてどういう構造になっているのか、正確に把握しませんでした。資料を読むことにより構造が解り、ボトルネックが発生した時にどう対処すればよいのか、より掴みやすくなりました。簡単にまとめてみたいと思います。 EBSの全体像 まずはEBSの基本構造です。当たり前といえば当たり前ですが、EBSはEC2ではなくその下のレイヤーのハイパーバイザにアタッチされます。アタッチ後にOSから認識させるという形になります。また接続の方式としてはネットワーク型ですが、利用者はネットワークを全く意識せずとも使えるようになっています。(SecurityG
はじめに AWSチームのすずきです。 Amazon CloudWatchのアップデートで、AWSサービスの主要なメトリックを一覧表示するAutomatic Dashboardsの提供が開始され、 AWSリソースの稼働状況の確認が簡単に出来るようになりました。 オートスケールなWebサービス基盤が動作している弊社AWSアカウントで、サービス間ダッシュボード(Cross service dashboard )と、主要なAWSサービス毎のダッシュボード表示を確認する機会がありましたので、紹介させて頂きます。 Amazon CloudWatch Introduces Automatic Dashboards to Monitor all AWS Resources Cloudwatch画面 AWSコンソール、Cloudwatchのリンクで表示されるページに、 「AWSのサービスの概要」と、「サービ
弊社では、基本的にどのプロジェクトでも CircleCI を利用して、 CI/CD を行っている。 ただ、お客様によっては、AWS環境で CI/CD も完結させたいというご要望もある。 今回は、普段 CircleCI で行っている CI/CD を、 AWS CodeBuild を使って行う場合の注意点をまとめてみる。 前提 今回の前提条件としては下記のとおりとなっている。 開発環境は、 docker-compose で、アプリ用コンテナ、DB用コンテナなど複数のコンテナを使って開発を行っている CircleCI でも、複数のコンテナを使って、テストをしている AWS CodeBuild でも複数コンテナを使ってテストをしたい AWS CodeBuild で複数コンテナ使いたい CircleCI 2.0 では、Using Multiple Docker Images に記載があるとおり、 I
ベルリンの半瀬です。 はじめに RDSのI/Oクレジットバランス周りで調べ物をしたときのメモです。 ボリュームタイプとI/Oクレジットバランス(I/Oクレジット)の基本 RDSは、データベースとログのストレージとして EBSボリュームを使用している。 ボリュームタイプに汎用SSDを利用している場合、サイズに比例するI/Oのベースラインパフォーマンスが決まっている ベースラインパフォーマンスを超えたI/Oリクエストを受けることは可能 ベースラインパフォーマンスを超えたI/Oリクエストを受けている場合、超過分のI/Oクレジットが消費される(バースト) ボリュームの初期作成時に、5,400,000 I/Oクレジットが割り当てられる I/Oリクエストがベースラインを下回った(バーストが終わった)場合、I/Oクレジットは補充されていく I/Oクレジットの補充速度はボリュームサイズに比例して速くなる
はじめに 超巨大な台風8号が近づく中、瞬間最大風速75mってどんだけ?と思う今日この頃、皆様いかがおすごしでしょうか? ちなみに、風速と感覚と被害 - いさぼうネット によれば、50mで「たいていの木造家屋が倒れる。樹木は根こそぎになる」、60mだと「鉄塔が曲がることがある」 とのこと。 恐ろしや。 前回の記事 EC2のt1.microをt2.microへ移行する の中で t2.micro のパフォーマンスに関して 「別記事で書こうと思います」 と書きましたが、今回簡単ですが t1.micro との比較した結果に関して載せてみます。 ディスクを Magnetic(Standard) のままにした場合だけでなく、SSD(General Purpose) に変更した場合の結果に関しても記載します。 テスト回数をそれほどこなしていないのである程度のブレはある可能性がありますが、移行を検討する場合
つい先日、どこぞのサーバからEC2のサーバに対してDosアタックを受けました。 別にある程度の攻撃を受けること自体は想定してサーバを公開していましたし、 Apache側ではmod_dosdetectorというDos攻撃をある程度受けた場合、検知出来る仕組みを用意していたので特に問題ない、、、と思っていました。 stanaka/mod_dosdetector · GitHub が、しかし。 Apache側で検知するということは、WEBサーバのリソースを結構食っちゃうんですよね…。 実際、普段5%以内で収まっていたCPU Usageが、攻撃を食らっている間50%オーバーをずっとマークしていました。 真ん中の跳ねてるグラフが攻撃受けてた期間ですね。 さすがに運営に支障が出るレベルだったので、出来ればWEBサーバの前に立っているELBにアクセス来た時点で、対象の攻撃者IPを弾いて欲しかったんですが
西澤です。みんな大好きAWS CLIで地味に嬉しいアップデートがあったのでご紹介します。 Release: AWS Command Line Interface 1.10.18 : Release Notes : Amazon Web Services 意外に取りづらかった自分のAWS Account ID これまでAWS Account IDを取得する方法って確立された方法がありませんでした。下記記事のように皆さん工夫していたのが実情かと思います。 【Tips】AWS CLIでAWSアカウントIDを取得する方法 | Developers.IO 意外にわかりづらかった今使用しているプロファイル 特に複数アカウントを切り替えて利用する環境では、今AWS CLIで使っているprofile情報が何なのか非常にわかりづらかったと思います。aws configure listで切り分けをして確認する
西澤です。今回Elastic Beanstalk環境を構築した際に、アプリケーションサーバのSecurity Groupの管理をどのようにすべきか検討したので、まとめておこうと思います。ELBに適用されるSecurity Groupについては、デフォルトに任せておけば良さそうなので、今回の焦点はAuto Scalingで動作するEC2に割り当たるSecurity Groupの話です。 前提 今回検討したEB環境は、デフォルトVPCではなく、カスタムVPC内に構築したアプリケーションを対象とします。 デフォルトでアプリケーションサーバに割り当たるSecurity Group まずは、suzuki.ryoさんの記事をご欄ください。 [Elastic Beanstalk] eb環境のSecurityGroup(ELB,EC2)を設定してみた | Developers.IO アプリケーションサーバ
項目ごとにコメントしてみます。 Dockerサポート/AMIの制限 EC2インスタンスでは仮想マシンのroot権が握れるので、AMI(Amazon Machine Image)があれば好みのLinuxディストリビューションにDockerをインストールして利用できます。商用サポートを期待するのであれば、CoreOSやRHEL Atomic Hostを検討するのも良いでしょう。 ECSの場合はECSエージェントを実行していれば任意のディストリビューションで良いようですし、ECSエージェント自体Dockerコンテナで実行するので、ほぼ縛りなしと見なしてよいと思います。一方Beanstalkは、専用AMIからの起動が前提になっているのでディストリビューションはAmazon Linux一択です *1。そもそも「Dockerを利用するモチベーションとしてLinux環境に依存したくない」というのもよくあ
はじめに 清水です。AWS上でWowza Streaming Engineを構築して、スマホ(iPhone)上のWowza GoCoderからの映像をライブストリーミング配信してみたのでまとめたいと思います。 ライブ配信とVOD配信の違い 以前のエントリで、Wowzaを使ったVOD配信についてまとめています。 AWSのWowzaでVOD配信してみた | Developers.IO 今回のエントリでは、VOD配信ではなくライブ配信を行ってみます。ライブ配信とVOD配信の違いは、先日行われた"AWS Black Belt Online Seminar 動画配信 on AWS"のスライドに詳しく説明されています。(オンデマンド配信=VOD配信です) 言い換えると、オンデマンド配信(VOD配信)はビデオ録画したものを見るイメージで、ユーザにより早送りや巻き戻しのコントロールが可能なもの。対してライ
Apple仕様のHTTP Live Streaming(HLS)をアダプティブ配信する環境をAWS(Amazon Elastic Transcoder→S3→CloudFront)で構築して、配信最適化できるか試してみた。 ※Akamaiでの配信方法は以下 動画配信技術 その1 - HTTP Live Streaming(HLS) - Akamai Japan Blog 動画配信技術 その3 - Universal Streaming(HDS/HLS) - Akamai Japan Blog HTTP Live Streamingとは、容量の大きい動画ファイルを10秒ごとに分割して、読み込みながらでも再生できる。特別なストリーミングサーバを必要とせず、通常のWEBサーバで配信ができるのも利点。iOS、Androidともに対応端末が幅広い。 Apple公式の資料 「特別なサーバソフトを使用し
こんにちは。CYBIRDエンジニア Advent Calendar 9日目のgucchonです。 新卒2年目、webエンジニアです。 8日目はkeitarouさんのGitHubをもっと便利にするためのChrome拡張とかでした。 全くGitHub使えてなかったんだな…と身にしみる内容でした。お恥ずかしながら… 本日の内容 「サーバ費、もっと下がらない?」 なかなか聞きたくない言葉ですね。サービスを継続させていく上では当然コスト面をしっかり考えて運用をしていかなくてはいけないのですが、まぁ正直めんd...少しばかり手間です。ただ、AWSならある程度簡単にコスト管理ができて、対応策も用意されているので助かりますね。それでも誰もやりたがらないけど(ボソッ ということで、コストを下げろと言われてしまったとき、CYBIRDのコストカッター、gucchonがまずやっていることをご紹介したいと思います
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::example-bucket", "arn:aws:s3:::example-bucket/*" ] }, { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" } ] } Statementを2つ設定してやるのがポイント。 1つ目のStatementは example-bucket に対するフル権限を与えている。Resourcesが/*付きのバケット名だけだとバケットのルートディレクトリで一覧取得できないので、バケット名そのものにも権限を与えている。 2つ目のStatementはバケット一
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く