タグ

awsに関するomomomのブックマーク (12)

  • 「サル軍団」にシステム障害を起こさせる、Netflixの驚異的なトラブル撲滅法

    Netflixは、わざと番障害を起こしてすぐ復旧させることを繰り返し、当の障害発生に備える、という驚くべき手法「カオスエンジニアリング」を実践している。 その効果は実証されている。Netflixが全面的に採用しているAmazon Web Services(AWS)で、2017年2月に中核施設の一つ、米バージニア北部リージョン(広域データセンター群)にて大規模障害が起きたとき、別のリージョンに速やかに切り替えたという。 Netflixの先進的な取り組みを紹介するこの特集の最後に、カオスエンジニアリングを取り上げる。

    「サル軍団」にシステム障害を起こさせる、Netflixの驚異的なトラブル撲滅法
  • Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD

    あるシステムを、1人のユーザから1100万人以上にスケーリングするにはどのようにすれば良いのでしょうか。Amazonのウェブサービスソリューションアーキテクトである Joel Williams が AWS re: Invent 2015 Scaling Up to Your First 10 Million Users でスケーリング方法について素晴らしいプレゼンをしています。 AWS上級者のユーザには適さないプレゼンですが、AWS初心者やクラウド初心者、Amazonが次々と送り出す新機能の流れについていけていない人が始めるには素晴らしい内容だと思います。 おおよその見当は付いていると思いますが、このプレゼンはAmazonによって提供されているため、どの問題についても解決策として提案されているものは全てAmazonのサービスになります。amazonのプラットフォームの役割は、印象深く、分か

    Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD
  • 「突然落ちて当たり前」にエンタープライズITは堪えられるのか?

    少し前の話ですが、シアトルのアマゾン社に出掛けて米Amazon Web Services(AWS)の幹部の前でプレゼンをする機会がありました。 前回のこの連載「AmazonがエンタープライズITを『ぶっつぶす』」でも述べたとおり、私は「AWSはクラウド時代の鍵となる存在」と考えています。その一方で、現状の日のエンタープライズITシステムをAWSに移行させるには、技術的、社会的にハードルがあり、簡単ではないとも見ています。 野村総合研究所(NRI)はAWSが日で最初に認定したプレミアコンサルティングパートナーです。AWSを使ったシステム構築の経験は既に幾つもあります。その経験から率直に言うと、AWSを使ったシステム構築は喧伝されるほど容易ではありません。 こうした問題意識があったのでこの機会に、日のエンタープライズITの現場の実情をAWSの幹部に理解してもらい、システム構築や運用を容

    「突然落ちて当たり前」にエンタープライズITは堪えられるのか?
  • 専門家が明かすAWSのコスト削減策(2)

    AWSを安く使うにはコツがある。オンプレミス環境と同じように考えていては、コストが高くなる一方だ。PART4では、コスト削減に効果がある九つのポイントを専門家が解説する。 狙うべきは九つのポイント サーバー乱立には要注意 4 一時的なサーバーは入札で買う スポットインスタンスの利用場面 EC2で使い方が難しいのは、スポットインスタンスだろう。前述のように入札額よりも相場が上回れば自動的に停止する。しかし、この料金体系も工夫次第で有効なコスト削減策となる。 写真1は「c3.xlarge」のスポットインスタンスの価格の推移である。c3.xlargeのオンデマンドインスタンス価格は0.255ドル。これに対してスポットインスタンスの価格は0.05~0.1ドルだ。つまり、スポットインスタンスは、オンデマンドインスタンスの半額以下の価格である。とても魅力的な料金だ。だが繰り返しになるが、相場が入札額を

    専門家が明かすAWSのコスト削減策(2)
  • [3]社内でAWSファンが急増、一方で情シスはピンチに

    前回、AWS(アマゾン・ウェブ・サービス)を基幹システムに使うに当たって準備した、共通基盤について説明した。今回は次なる壁として、この基盤にいかに社内ユーザーを呼び込んでいくかについてお伝えする。 次期の主要インフラにAWSを採用するという方針が決まってから、我々情報システムセンターは、製造部門や研究開発部門などいくつかの部署を対象に、AWSに関する説明会を実施した。そこでは、「AWSの超入門」「代表的なAWSのサービス」「AGC旭硝子におけるAWSの使い方(指針)」といった項目について説明した。 反応は実に様々だった。「ぜひ、次期システムにAWSを使いたい」と言ってくれるユーザーもいれば、「コストが見合うのなら検討する」という慎重派のユーザーもいた。もちろん、「自分が担当しているシステムは、AWSでは実現できない」という人もいた。 社内からの相談が急増し「これはヤバい」 いずれにせよ、説

    [3]社内でAWSファンが急増、一方で情シスはピンチに
  • 実践Cloud DIパターン – 環境ごとにApache設定ファイルを読み分ける | DevelopersIO

    はじめに Cloud DIパターンというCloud Design Pattern(CDP)があります。 CDP:Cloud DIパターン - AWS-CloudDesignPattern AWSではAMIで好きなサーバをいくらでも増やすことが可能です。ですが、例えば開発環境のサーバでAMIを取得し、それを番環境用のサーバとして起動したとします。果たしてそのサーバは正常に機能するでしょうか。恐らく多くのパターンでは番サーバとして振る舞うことができないのではないかと思います。理由は単純で、サーバの設定が開発環境用になっているからですね。 せっかくAMIでサーバを複製できるので、開発環境と番環境がひとつのマシンイメージから起動できたら非常に楽になると思います。それを実現するための一つのパターンがCloud DIです。EC2のタグに記載された情報を読み込み、それを利用してサーバの振る舞いを変

    実践Cloud DIパターン – 環境ごとにApache設定ファイルを読み分ける | DevelopersIO
    omomom
    omomom 2015/04/23
  • 社内の GitHub Enterprise を OpenStack に移行した, α7s Ver 1.21 にアップグレードした - HsbtDiary(2015-04-06)

    ■ 社内の GitHub Enterprise を OpenStack に移行した 勤務先のペパボでは GitHub Enterprise(GHE) を全社員使っていて、コードやアイデアや作業記録をすべて集約するようにしているのだけど、全社員となると導入した当初に用意したリソースではどうしても厳しくなってきた。さらに使用していた VirtualBox は GHE 2.x シリーズはサポート対象外となってしまい、未来に向けてなんとかしなくてはいけないということでなんとかした。 取りうる選択肢としては、AWS にのせるとか ESXi をインストールしてその上にのせるなどがあったのだけど、弊グループでは大規模な OpenStack 基盤の運用ノウハウがあるということと、ペパボでもアプリケーション・サーバーは積極的に OpenStack の上に載せていくという動きがある(と言っても動きを作っている

    社内の GitHub Enterprise を OpenStack に移行した, α7s Ver 1.21 にアップグレードした - HsbtDiary(2015-04-06)
  • AWS で不正アクセスされて凄い額の請求が来ていた件 - yoya's diary

    情けない話ですが、自分の大チョンボで AWS の個人アカウントが第三者にアクセスされた結果 190万円相当のリソースが使われ、最終的に AWS さんに免除を頂きました。反省込みで件のまとめを書きます。 自分が馬鹿を幾つも重ねた結果であって、AWS 自体は怖くないというのが伝われば幸いです はじめにまとめ S3 実験してた時に SECRET KEY を見える場所に貼っていた事があり、第三者がそれでアクセスし大量の高性能インスタンスを全力で回す (恐らくBitCoin採掘) AWS さんから不正アクセスの連絡があり、急いで ACCESS KEY 無効&パスワード変更、インスタンス全停止、イメージ削除、ネットワーク削除 免除の承認フェーズを進めて、クレジットカードの引き落とし前に完了して助かる AWS さんのサポート AWS さんは最大限サポートしてくれました 承認フェーズが進まない時もあまり

    AWS で不正アクセスされて凄い額の請求が来ていた件 - yoya's diary
  • Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note

    TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済

  • 【鍵管理】~/.aws/credentials を唯一のAPIキー管理場所とすべし【大指針】 | DevelopersIO

    よく訓練されたアップル信者、都元です。AWSを利用していると、APIキーの利用は必要不可欠です。数多くのAWSアカウントを扱っていれば、たまたまAPIキーは利用せず、管理コンソールへのパスワードだけで済んでしまうケースもあるかもしれませんが、これはごく例外的な状況です。しっかりとAWSを使いこなしている以上、APIキーを管理する機会が必ずあります。 鍵管理が大変 というわけで、皆さんは自分用のAPIキーを数多く管理しているわけですが、その管理は行き届いているでしょうか。少なくとも「失くしたwww」なんていう事態は是非避けたいものです。大丈夫すか? では、とあるキーがありましで、それが書き込まれている場所を全て挙げられますか? あちこちのファイルに書き込んだりしていませんでしょうか。aws-cli用の設定ファイルはもちろん、環境変数設定用の~/.bash_profileの中、シェルのhist

    【鍵管理】~/.aws/credentials を唯一のAPIキー管理場所とすべし【大指針】 | DevelopersIO
    omomom
    omomom 2015/02/13
  • https://docs.aws.amazon.com/s3/

    omomom
    omomom 2014/12/15
  • Amazon S3(拡張性と耐久性を兼ね揃えたクラウドストレージ)|AWS

    Amazon Simple Storage Service (Amazon S3) は、業界随一のスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。あらゆる規模や業種のお客様が、データレイク、クラウドネイティブアプリケーション、モバイルアプリケーションなど、事実上あらゆるユースケースで、あらゆる量のデータを保存、保護することができます。コストパフォーマンスに優れたストレージクラスと使いやすい管理機能により、コストの最適化、データの整理、特定のビジネス、組織、コンプライアンスの要件を満たすきめ細かなアクセスコントロールの設定を行うことができます。 この図は、データを Amazon S3 に移動し、Amazon S3 に保存されたデータを管理し、他のサービスでデータを分析する方法を示しています。左から右に 3 つのセクションが表示されます

    Amazon S3(拡張性と耐久性を兼ね揃えたクラウドストレージ)|AWS
    omomom
    omomom 2014/12/15
  • 1