こんにちは、エンジニアのtarr [https://github.com/tarr1124]です。 KARTE Blocksは既存のサイトにタグを一行入れるだけで、そのサイトを簡単に書き換えたり、ABテストなどで最適化したりできます。 これは、サイトを読み込むときにタグによってBlocks内で設定された内容を反映させているのですが、既存のサイトの挙動に手を加えている以上、一定のリスクが存在します

AWSの主な通信料を1枚もので記載しました。 日々AWSは新サービス、値下げを繰り返しているので最新情報はAWS公式ドキュメントをご確認いただきたいですが参考資料として役にたてば幸いです。 @ohsawa0515さんの作成されていた画像を参考に作りました！ AWSのネットワーク・データ転送料金がひと目で分かる図を作った。Direct ConnectとGlobal Acceleratorは描ききれんかった･･･ pic.twitter.com/97RM8fxgbe — shu1 (@ohsawa0515) January 30, 2020 上記画像の補足、ケース別の料金計算例などを以下に記載していきますので参考になれば幸いです。 EC2の通信料(コスト)について こちらの情報は2023/03/05時点の情報です。 AWSはコストダウンを定期的に行っておりますので情報が古い場合がございます。

Amazon Web Services（AWS）は、開催中のオンラインイベント「AWS re:Invent 2020」で、アプリケーションに対してクラウド障害のシミュレーションを行える新サービス「AWS Fault Injection Simulator」を発表しました。 クラウド上で稼働するアプリケーションの耐障害性などを高めるために実際にクラウド障害をわざと発生させて問題点をあぶりだす手法は、「Chaos Enginieering（カオスエンジニアリング）」と呼ばれています。 Netflixが2012年にカオスエンジニアリングのためのツール「Chaos Monkey」を公開したことで広く知られるようになりました。 参考：サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 今回発表された「AWS Faul

中山です ソリューションアーキテクトとして、AWS環境の利活用をお手伝いするお仕事をしています。 まれによく見るAWS環境 とりあえずこれを見てほしい。 これが絶対にだめと言いたいわけではないです。 一時的な検証環境だったり、とにかくスピード重視でサービスをデリバリーさせる必要があったり、サービスの提供者側が何ら責任を負わない・障害時のビジネスインパクトが無い（そんな状況あるのか？）という前提があったり、状況次第ではこれで十分な時もあると思います。 しかし、一般的な業務システムやサービスの場合にはいろんな意味で不十分でしょう。 では、このような環境をどのように育てていくとよいでしょうか。 この記事では、そんな育てかたの一例を紹介していきたいと思います。 なお、本記事はくっそ長いです。 ちなみに、最終的にはこうなります。 文字が小さすぎて読めない！ ちょっとそこのハ○キルーペ貸してくれーｗ

水平分散のアーキテクチャを考えるときに、「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」「AWS であれば３ AZ にまたがるとよい」とはよく聞かれます。それがどういう意味をもつのか、主に可用性の面から考えてみました。 みなさん、AWS使ってますか！（挨拶 AWSに限らず、ある程度の規模の何かしらの本番システムを組もうというときに、こういう言葉を聞いたことはないでしょうか。 「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」 「AWS であれば３アベイラビリティゾーン (AZ) にまたがるとよい」 負荷分散装置（ロードバランサー）は負荷を分散するのがお仕事です。分散するだけなら 2 台でもよさそうですよね？ AWS の３ AZ に至っては、そもそも AZ 単位の障害なんてそうそうないし、あったとしてももう片方の AZ が生きていればなんとかなりそうに思えます。

西澤です。クラスメソッドに入社してからおよそ5年間クラウドの推進やAWS技術に関する支援をさせていただいております。この経験を何か形にしたいと思い、少し遅れてしまったのですが、Developers.IOイベントに乗じてまとめさせていただきました。 発表資料 資料はこちらにアップロードしております。 夜間に録音したので覇気が無い感じになってしまいましたが、動画はこちらです。 まとめ 「AWS設計でやりがちな失敗パターン」というタイトルで考え始めたのですが、もっともお伝えしたい点は、AWSを利用されるお客さまのマインドセットを変え、クラウドを活用できる組織に変わって欲しい、というところに集約できるかなと思います。技術的な問題以上に、考え方を変えられないこと、組織を変えられないことが、クラウド活用を阻害するアンチパターンになっていると思いました。 どこかの誰かのお役に経てば嬉しいです。

先週金曜日、お盆明けの日本列島をAWSの大規模障害が襲いました。影響を受けた会社は多数に上ったようで、その数だけ緊急対応に当たった担当者の方々がいるわけですよね。大変お疲れ様でした。 【AWS障害】AWSの東京リージョンで大規模通信障害 エンジニアが悲鳴「もう帰ろうぜ」8/23 冷却システムの制御がうまくいかず、サーバーがオーバーヒートしたということですが、いろいろとフェイルセーフの仕組みが組込まれていたにも関わらず、一部の制御装置が正常に動作しなかったということで、不幸が重なった結果とも言えそうです。一方で気になるのは、ユーザー側は適切な冗長化対応を行っていたのかどうかと言う点です。 こういうことが起きると、「やはりクラウドは安心できない」という話になりがちですが、もそもクラウドサービスが「高可用性」を謳ったことは無く、元々可用性は低いのです。クラウドには圧倒的なメリットがあります。クラ

技術部 SRE グループの mozamimy です。 クックパッドでは、 SRE が中心となって、サービスを動かす基盤の大部分である AWS のコスト最適化を組織的に取り組んでいます。 昨年夏に公開した記事である、インフラのコスト最適化の重要性と RI (リザーブドインスタンス) の維持管理におけるクックパッドでの取り組みでは、 なぜインフラのコスト最適化が必要なのか、具体的にどのような考え方に沿って進めてゆけばよいのか。 SRE が一括して管理する AWS のリソースプールそのもののコスト最適化を実践するための具体的な取り組みの一例として、RI のモニタリングや異常時の対応フローによる維持管理。 といった話題にフォーカスしました。 今回は、インフラにかかるコストを正しく「説明」するための取り組みということで、コスト最適化に貢献する社内アプリケーションである Costco (Cost Co

はじめに 最近、AWSのシステム構成図を見ることが多くなり、AWS上で動いているシステムのシステム構成図を理解できるようになるために個人的に知っておきたいと思ったAWSの用語・サービスをまとめてみました。 私自身も勉強がてら作成したので、わかりづらい部分も多くあると思いますが、AWSのサービス全くわからん→なんとなく雰囲気把握した、となっていただけたらと思います。 2018年10月に新しくなったAWSアーキテクチャアイコンを使用しています。 サーバ・クライアントなどの説明についてはここではしていませんが、以下の記事でとてもわかりやすくまとめてくださっています！ 超絶初心者のためのサーバとクライアントの話 知っておきたい用語 リージョン AWSがサービスを提供している拠点（国と地域） リージョン同士はそれぞれ地理的に離れている（例えば日本とオレゴンとか） 日本はap-northeast-1（

AWSボリュームに暗号化は必要なのか？ 当初、実際にAWSのデータセンターの実サーバーに物理的に侵入された場合や、AWSの管理システムへのハッキングした時くらいにデータを守れるという認識だったのでそれが正しいのかどうかAWSサポートに問い合わせをしてみた. AWSサポート問い合わせ結果(原文は載せれないので要約) 1. お客様のセキュリティあるいはコンプライアンス要件を満たせるようにご用意している機能 多くのユーザーはこのコンプライアンス基準へ準拠のためだけに、ストレージ暗号化の機能を利用しているのが現実らしい 2. AWSのデータセンターに対して物理的な侵害が発生した場合に、保護する事が可能になる これは想定していた当然のメリットである. 3. EBS と EC2 インスタンスとはネットワークを経由で通信するが、暗号化ボリュームを使用している場合この通信経路上も暗号化される これは少しび

Amazon Web Services ブログ 実際に手を動かして学ぶ！AWS Hands-on for Beginners のご紹介 こんにちは、テクニカルソリューションアーキテクトの金澤 (@ketancho) です。本日は、先日 11/6 に公開した「AWS Hands-on for Beginners」について紹介します。 みなさまは AWS のサービスを使い始めるときに、どのように学習をされていますか？私は日々、様々な業種のお客様とお話しさせてもらう機会があるのですが、その中で学習方法についてもご相談をいただくことがあります。キャッチアップの方法は様々あり、人によって最適な方法は違ってくると思うのですが、私個人のオススメ勉強方法は「実際に手を動かしてみる」ことです。実際にそのサービスを使ってみることで、構築の流れであったり、細かい機能であったりを知ることができ、机上で学んだ知識が

弊社クラスメソッド株式会社主催のイベント「Developers.IO 2019 TOKYO」での登壇資料です。 セキュリティ対策メガ盛りマックス ブログ: https://dev.classmethod.jp/cloud/aws/developers-io-2019-tokyo-all-security-in-aws/ ハッシュタグ: #cmdevio ブログの方に喋った内容の補足など入れてあります ちなみにブログをシェアしてくれると喜びマックス

Presented by Yoshiya Ito and me, Takeshi Matsuda at "ServerlessDays Tokyo 2019"

AWS、Amazon PrimeやKindle、Alexaなどで使用していた約75ペタバイト7500のOracleデータベースをダウンタイムなしで自社データベースサービスへ移行したと報告 AWSはAmazon PrimeやAmazon Music、Alexa、Kindleなどを含む同社のコンシューマ向けビジネスで使われていた75ペタバイト、7500個以上のOracleデータベースを、ダウンタイムなしでAWSのデータベースサービスであるDynamoDBやAman RDS、Aurora、Redshiftなどへ移行したことを明らかにしました。 下記は今回移行を完了したシステムです（「Migration Complete – Amazon’s Consumer Business Just Turned off its Final Oracle Database」から引用） This include

スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも？？？ Amazon EC2をステートレスにする為にやるべきこと セッション管理が必要なWebアプリケーションを使う場合でも､スティッキーセッションを利用しない方法を説明します｡また､ログをインスタンス内に保持しない方法やAuto Scaling化についても触れています｡ はじめに おはようございます､加藤です｡煽り気味なタイトルで申し訳ございません､念の為より詳細に記載しますが､スティッキーセッションを使っていなければApplication Load Balancer障害の影響を受けるのを防げたかもしれないという内容です｡ 今後同様の障害への対処として､このブログの対応は行う価値がありますが､これだけやっておけばOKという事では無い事をご理解ください｡ 2019年8月23日にAWS

https://builderscon.io/builderscon/tokyo/2019/session/6509eeb6-356b-4f77-b709-823f138da640

AWS、複数のアベイラビリティゾーンで稼働していたアプリケーションでも大規模障害の影響があったと説明を修正。東京リージョンの大規模障害で追加報告 2019年8月23日金曜日の午後に発生したAWS東京リージョンの大規模障害について、AWSは追加の報告を行い、複数のアベイラビリティゾーンで稼働していたアプリケーションでも障害の影響があったことを認めました。 下記は大規模障害の報告ページです。赤枠で囲った部分が、8月28日付けで追記されました。 当初の報告は、障害の原因が空調装置のバグであり、それが引き金となってサーバーのオーバーヒートが発生したことなどが説明されていました。 そして障害の影響範囲は単一のアベイラビリティゾーンに閉じており、 複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。 と説明されていました。 複数のアベイ

AWS障害、“マルチAZ”なら大丈夫だったのか？　インフラエンジニアたちはどう捉えたか、生の声で分かった「実情」（1/3 ページ） 8月23日に起きたクラウドサービス「AWS」（Amazon Web Services）の東京リージョンでの障害は、国内のさまざまなサービスに影響を及ぼした。 AWSが同日午後8時ごろに復旧するまで、モバイル決済サービス「PayPay」や、仮想通貨取引所「Zaif」、オンラインゲーム「アズールレーン」などで利用できない、もしくは利用しづらい状況が続いた。PCショップの「ドスパラ」はECサイトの不具合が長引き、翌日の24日には実店舗を臨時休業して対応に当たっていた。 AWSという1つのサービス障害が起きただけで、多くの企業やサービスに影響を及ぼしたため、「クラウドサービスはもろい」という論調も散見された。 しかし、インフラエンジニアたちからは違う意見が聞こえてくる

昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装（の予想） マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB（CLB）をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス（仮称）として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが