Amazon EC2への侵入テスト申請について | DevelopersIO
最新の情報は以下ブログをご参照ください。 2017年版 AWSの侵入テストについて はじめに 今日はAWSの侵入テストの申請についてまとめたいと思います。 代行して申請する際にお客様にヒアリングをしている内容となります。 AWSの侵入テスト申請 AWS環境にて侵入テスト・脆弱性スキャンを実施する場合は、事前にAWSに申請を行い許可を得る必要があります。 事前に申請が必要な理由は、侵入テスト・脆弱性スキャンをAWSの適正利用規約と区別するためです。 侵入テストページからの引用 私たちの適正利用規約には、禁止されたセキュリティ違反およびネットワーク不正利用の説明を含む、 AWS 上で許可される行為および禁止されている行為についての説明があります。 しかし、侵入テストはこれらの行為と区別できないことがよくあるため、 当社は侵入テストおよび脆弱性スキャンを実施するための許可をお客様が申請できるポリ
Amazon EC2から負荷テストを行うときの落とし穴と対策 | DevelopersIO
ども、大瀧です。 ここのところ新機能を追いかける記事ばかりだったので、今回は少し毛色の異なるノウハウ系を書いてみます。 負荷テストの前置き(読み飛ばし可) 「Webサイトがテレビ番組で紹介されることになった！大幅なアクセス増がやってくる！」という場合に、ロードバランササービスのElastic Load Balancing(ELB)やCDNのCloudFrontなどスケールするサービスを組み合わせ乗り切るというのは、クラウドらしい柔軟性の高さを活かせる典型な例かと思います。実際、弊社の事例でも多くのお客様に提供し、ご好評をいただいています。 これらのサービスを構成するにあたり、実際のアクセス増に耐えられるか試すため負荷テストを実施することも多いと思いますが、大規模なケースになってくると難しいのが負荷テストを実施するマシンの確保です。これについてもAmazon EC2であれば、Auto Sca
SpotInstanceとJMeterを使って400万req/minの負荷試験を行う | DevelopersIO
Apache JMeterのMaster/Slave構成 シナリオを用いた負荷試験といえばJMeterということで、使ったことがある方も多いかと思います。しかし、ほとんどの方は自分のPCを使ってやっている程度ではないでしょうか。最近は、スマホ連動のシステムが多くなってきていますので、1台のPCから負荷を掛けたとしても大した負荷試験になりません。そこで、今回はJMeterをMaster/Slaveのクラスター構成にしてドカーンと同時アクセスを行いたいと思います。 クラスメソッドの負荷試験の歴史 創業時から業務系のシステム開発が多かったことから、レスポンスは3秒以内でOKとか、ピーク時の同時ユーザは100名といった、緩い条件をクリアすれば良かったことが懐かしく思います。今は、ユーザ数・データ量・トランザクション数・トラフィック等が爆発的に増える可能性のあるプロジェクトも多く、負荷試験は必須項目
JMeterのMaster-Slave構成で目標スループットから負荷設定値を決める | DevelopersIO
目標リクエスト毎秒は 発行するリクエスト総数/総秒数 です。よって、JMeterのMaster-Slave構成の負荷試験においては、これらの変数の関連を次のように表現できます。 [latex] RPS = \frac{Slaves \cdot Threads \cdot Loop}{RampUp} [/latex] このうち、目標リクエスト毎秒（RPS）は今回の前提で固定値になります。また、ほとんどのケースではスレーブ台数（Slaves）とRamp-Up期間（RampUp）があらかじめ決まっていると思います。 その場合には、未知数がスレッド数（Threads）とループ回数（Loop）のみになります。これらの値は次の式で表現できます。 [latex] Threads = RPS \cdot \frac{RampUp}{Slaves \cdot Loop} [/latex] [latex] L
（祝）AWS LambdaのVPC利用が可能になりました ｜ DevelopersIO
はじめに AWSチームのすずきです。 2015年の秋にアナウンスされたAWS LambdaのVPC対応、本日から東京を含むAWSの各国リージョンで利用可能になりました。 LambdaファンクションをVPC内に起動させてその動作を確認する機会がありましたので、紹介させて頂きます。 Release: AWS Lambda on 2016-02-11 [New] LambdaファンクションからのVPC内リソースへのアクセス 手順 コンソール指定 Lambdaファンクションの作成、AWSコンソールを利用しました。 Lambdaファンクション作成 Lambdaファンクションを起動します。 今回、サンプル（blueprint）の「Hello-world」を利用しました。 ファンクション名は任意の名称とします ロール指定 Roleは、「ec2:CreateNetworkInterface」を付与済みのロ
VyOSをAWSで使う時によくやることをまとめてみた | DevelopersIO
最近、VyOSと戯れることが多い市田です。 別リージョンとのVPN接続などの際に、ソフトウェアルータであるVyOSをよく利用します。今回は、VyOSをAWS上で作成する際にやることをまとめてみました。 前提の構成 下記のような構成を想定して説明していきたいと思います。 VyOSでVPN接続するまで 基本項目 MarketplaceからVyOSインスタンスを作成できたら、下記の項目を対応していきます。 なお、対向のVPCで指定するAS番号は65000とします。 送信元/送信先チェックの無効化 VyOSバージョンアップ コンフィグ投入 configureコマンドで編集モードになって投入します。 コンフィグは東京側のVPCで「VPN接続」を作成した際にダウンロードできます。 「VPN接続」の作成については、下記の「対向VPC(VPC-Tokyo)の設定」の項目を参照してください。 ダウンロードし
VyOSをAWSで冗長構成で使う時にやること | DevelopersIO
まだまだVyOSを使うことの多い市田です。 今回は、VyOSを2台作ってActive-Standby構成を作ってみたいと思います。 想定環境 下図のようなVPN接続を冗長化した構成を考えてみます。 VyOSの後ろにあるELB以下については、今回のようなケースで考えられうる構成として記載したものですので、今回はここの構築は行いません。 できるだけVPCの機能を使うことを前提としているので、前回のVyOSまとめ記事と同様にVyOSをカスタマーゲートウェイとして利用しています。 構成の利点 VyOSをActive-Standby構成にすることで、EC2をホストしているハードウェア環境の影響でActiveのVyOSが利用不可になっても、自動的に待機系のStandby側のVyOSに経路を切り替えて利用することができます。 構成上のポイント 今回の構成でポイントになるのは、以下の3点です。 1.VyO
Amazon VPC Peeringの技術的考察と留意点 | DevelopersIO
大事なことなのでもう1回言います。今回のVPC Peeringは、2つのVPC間のL3ネットワーク通信を提供します。 ...言わんとするところ、伝わったでしょうか。伝わりにくいですかね?(笑)説明としては上の文章でいいのですが、思い浮かぶイメージと実現できることにはそれなりに隔たりがあるので、そこを理解いただきたいというのが今回のエントリーの狙いです。VPC Peeringの仕組みを自分なりに考察(≒妄想)し、そこから見えてくる留意点を紹介してみます。以下に要点をまとめます。 ルーティングの設計はユーザーが行う。 Peeringなので、2VPC間以外のルーティングを取り持つことはできない。 Peering経由でIGW/VGWは利用できない。 ルーティングの設計はユーザーが行う Peeringの設定は、VPCの[Peering Connections]画面で、作成・管理します。ただ、このPe
【新機能】新しいロードバランサー Application Load Balancer（ALB）が発表されました | DevelopersIO
target2の場合も同様に作成します。 ターゲットグループにインスタンスを登録する 作成したターゲットグループにEC2インスタンスを登録します。 ターゲットグループを選択してコンテキストメニューでインスタンスの登録と登録解除をクリックするか、ターゲットタブの編集をクリックします。 インスタンスtarget1-aとtarget1-cを登録します。 ALBにインスタンスが登録されます。ロードバランサに登録していないため状態はunusedとなります。 同様にtarget2にもインスタンスtarget2-aとtarget2-cを登録します。 ALBを作成する ALBを作成します。アプリケーションロードバランサーを選択します。 ロードバランサの基本的な設定を行います。 プロトコルはHTTPとHTTPSのみとなっています。今回はHTTPSを選択します。 HTTPSを選択したのでSSL証明書を選択しま
【AWS】非エンジニアのための初めてのAmazon Web Services 資料をまとめてみた | DevelopersIO
はじめに こんにちは植木和樹です。2013年2月2日は私がAWSに初めて触れた日で、本日が1周年となります。JAWS-UG北陸（金沢）の勉強会でアマゾンデータサービスジャパンの堀内さんによるハンズオン（実際に画面を操作しての体験会）が開かれ、そこでEC2やRDSを触れたのが初となります。 実際にはその3ヶ月ほど前から、ネットに流れてくるAWS関係のニュースをみたり、自分のクレジットカードを使ってアカウントを作ったりはしていたのですが、マネージメントコンソールを用いた操作をちゃんとしたのがこの日が初めてだったわけです。 さてAWSを始めた方の多くは、まずEC2にApache＋PHPを起動しRDSでMySQLを用意して・・・というエンジニア向けなところから入ってくる場合が多いようです。上記の通り私もその口で、それまで10年程やっていたインフラ（サーバー）エンジニアの延長としてAWSと関わり始め
Amazon Auroraの運用時に監視できる項目について | DevelopersIO
Amazon Auroraの運用について プレビュー版のAmazon Aurora使えるようになったので色々試しています。新しいDBエンジンということで、運用をどうするか気になっている方も多いのではないでしょうか。Amazon Auroraは、RDSの他のデータベースエンジンと同じように、CloudWatchで運用状況をモニタリングすることができます。これにより、正常稼働しているか、期待するパフォーマンスが出ているか確認することができますので、アラームを設定して運用に役立てることができます。 AuroraのDBクラスタ概念図 Aurora Metricsの種類 Auroraは、大きく分けて2種類の情報があります。Aurora System Monitoringと、Aurora SQL Monitoringです。前者は、ネットワーク/ディスク/CPUなどのシステムに関するモニタリングで、後者
AWS再入門 Amazon Redshift編 | DevelopersIO
はじめに 当エントリはDevelopers.IOで弊社AWSチームによる2015年アドベントカレンダー 『AWS サービス別 再入門アドベントカレンダー 2015』の4日目のエントリです。 昨日3日目のエントリは清水の『Amazon CloudFront 』でした。 このアドベントカレンダーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 本日4日目のテーマは『Amazon Redshift』です。 Amazon Redshift（クラウドデータウェアハウスソリューション） | アマゾン ウェブ サービス（AWS 日本語） 目次 サービスの基本的な説明 高速且つフルマネージドなデータウェアハウス(DWH:Data Ware Hou
【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO
はじめに こんにちは植木和樹＠上越妙高オフィスです。本日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 （この記事を読むのにかかる時間の目安：5分） 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1
クラスメソッドの社内制度と社風をご紹介します | DevelopersIO
はじめに クラスメソッドは「AWSの会社」「モバイルの会社」「ブログの会社」とよく言われており、エンジニアやブログを最初にイメージされる方も多いかと思いますが、「社員が働きやすい環境を作る」ことに関しても頑張っています。例えば以下のような認定を受けています。 短時間正社員制度導入支援事業（厚生労働省支援） ワーク・ライフ・バランス推進宣言企業（新宿区支援） 平成23年度男性の育児・介護サポート企業認定（新宿区支援） 平成23年度ワーク・ライフ・”ベスト”バランス賞受賞（新宿区） 平成24年度東京ワークライフバランス認定企業（東京都） そこで今回は、クラスメソッドの社内制度と社風をご紹介します。クラスメソッドがどんな会社なのか？を知っていただく一助になれば幸いです。 クラスメソッドの社内制度 フレックスタイム勤務 勤務体系としてフレックスタイム制を採用しています。コアタイムは11:00～15
[レポート]【ミクシィ様登壇】10 年オンプレで運用した mixi を AWS に移行した 10 の理由 #AWSSummit | DevelopersIO
はじめに こんにちは、中山です。 6/2(木) 13:20 〜 14:00 に実施された「10 年オンプレで運用した mixi を AWS に移行した 10 の理由」というセッションを聴講したので、そのレポートを以下に記述します。 セッション情報 株式会社ミクシィの北村さまに発表していただきました。こちらのURLより概要を引用します。 2014 年 3 月に 10 周年を迎えた mixi。なぜ 10 年以上オンプレミス環境で継続運用して きたサービスを AWS に移管することを決めたのか。サービスの成長を支えると共に大規模 化・複雑化してしまったインフラを、どのようにして AWS に移管したのか。 当時のサービ スを取り巻く社内外の環境を踏まえ、どのように移管を計画し、実行したか。そして、実際 に AWS に移管してどう変わったのかを実体験を元にご紹介します。 セッション内容 AWS移行を
![[レポート]【ミクシィ様登壇】10 年オンプレで運用した mixi を AWS に移行した 10 の理由 #AWSSummit | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/148d66c86adf4dd67af10f04029ebb83085d1632/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F06%2Faws-summit-tokyo-2016.png)
Spring SecurityでWebの認証と認可を制御する | DevelopersIO
よく訓練されたアップル信者、都元です。Webアプリケーションを書くにあたって、誰でも自由に全てのリクエストが呼べるなんていうユルユルな要件ってのはほとんど無いと思います。誰がからのアクセスかが特定できて、そのユーザが適切な権限を持っている場合に限り、アクセスが成功する必要があるでしょう。 Spring Securityの導入 v14.0 Spring Frameworkの世界の中で認証と認可を司るコンポーネントが Spring security です。 Spring BootプロジェクトでSpring securityを使うには、まずは依存ライブラリとして spring-boot-starter-security を追加します。え、まさかこれだけ？ → GitHub diff さぁさぁ、起動してみましょう。（以降、タイトルに示したバージョンのブランチをcheckoutして実行できるようにし
Web API サーバ負荷試験のすすめ方 – 観点を整理、負荷を試算、対象を選定 | DevelopersIO
負荷試験対策ミーティング ここでは、チームメンバーを集めて、システム要件の再確認と、バックエンドのアーキテクチャを再確認をまず行います。すなわち、「求められているもの=要件」と、「提供できるもの=アーキテクチャ」の確認です。ここの認識が揃っていないと、的はずれな負荷試験を実施してしまうことになりかねません。立場や役割にかかわらず、サービス全体として考えるべきです。 負荷試験の目的 負荷試験を行うことによって、何を示したいのか決めます。今回は、以下の目的を定めます。 サービスリリース後、想定されるピーク時のリクエストを受けた場合でも、問題なく稼働を続けられることを確認する システムのスループット限界値を確認する 負荷試験の観点 たいていのWebシステムの場合、昼夜を問わず稼働し続けるものとなるでしょう。今回例にとったシステムも24時間365日、リクエストを受け付けるものとします。この場合、観
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
Spring BootアプリケーションをAWSにデプロイする仕組み | DevelopersIO
よく訓練されたアップル信者、都元です。花粉が落ち着いてきた気がします。やっと春の空気を胸いっぱいに吸い込めます。 前回、Spring Bootで書いたアプリケーションをGradle、CloudFormation、Elastic Beanstalkを使ってデプロイするデモをご紹介しました。今回はその詳細をご紹介します。 Gradle 前回のデモでも示した通り、env/personal.gradle というファイルに環境固有の設定を記述しています。具体的には、AWSのアクセスプロファイル名（~/.aws/credentialsに記述してあるもの）や、デプロイ先のリージョン等です。 このファイルはbuild.gradle内で読み込まれ、その情報をタスク実行時に利用します。 gradle-aws-plugin このサンプルシステムをAWSにデプロイするには、Gradle上で下記のような手順を踏みま
CORS(Cross-Origin Resource Sharing)によるクロスドメイン通信の傾向と対策 | DevelopersIO
CORS(Cross-Origin Resource Sharing)って何？ CORS(Cross-Origin Resource Sharing)は、その名の通り、ブラウザがオリジン(HTMLを読み込んだサーバのこと)以外のサーバからデータを取得する仕組みです。各社のブラウザには、クロスドメイン通信を拒否する仕組みが実装されています。これは、クロスサイトスクリプティングを防止するためです。Aというサイトに訪問したのに、Bというサイトに向けて個人情報を送っていたというのは困りますよね。例えば、オリジンから読み込んだHTML内のJavaScriptでJSONデータを読み込むとしましょう。JSONデータが同じサーバにあれば普通に読み込めますが、別のサーバにある場合は読み込めません。まぁ実際のところはJSONPという仕組みを使ってできちゃったりしますが、抜け道的なやり方で使われていました。CO
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
