タグ

awsに関するslywalkerのブックマーク (74)

  • AWS 導入事例:任天堂株式会社、株式会社ディー・エヌ・エー| AWS

    Super Mario Run の配信を開始した当日は、待ちわびた世界中のユーザーからのアクセスが一気に集中しましたが、AWS のインフラは十分なレスポンスを返し続けてくれました。ここまで何も大きな障害が発生しないケースは、大量のアクセスが想定されるゲームの配信開始時では極めてまれなことですし、2017 年 3 月時点で 8,000 万ダウンロードを突破する規模になっても AWS で特に問題は起こっていません。 任天堂株式会社は「任天堂に関わる全ての人を笑顔にする」ことを目指し、ホームエンターテインメント分野において、世界中のユーザーにかつて経験したことのない楽しさ、面白さ、驚きを持った娯楽を提供することを最も重視しています。任天堂ではこれまで、ホームエンターテインメントのビジネスを主にゲーム専用機の提供で推進してきました。 さらに任天堂では、先進国が中心となっているゲーム専用機の利用者に

    AWS 導入事例:任天堂株式会社、株式会社ディー・エヌ・エー| AWS
  • 伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する(前編)。QCon Tokyo 2016

    クラウド上でアプリケーションを構築する新しい手法として「サーバーレスアーキテクチャ」が急速に注目を集めています。しかし一方で、サーバーレスアーキテクチャを採用することで得られる質的なメリットはなにか、そもそもサーバーレスアーキテクチャとはなにを指すのか、などについてはまだ識者の間でも議論されていることです。 10月24日に都内で開催されたイベント「QCon Tokyo 2016」の伊藤直也氏のセッション「Serverless Architecture」は、こうしたサーバーレスアーキテクチャの質について大きな示唆をもたらす内容でした。この記事では、その内容をダイジェストで紹介します。 (記事は前編、中編、後編に分かれています。いまお読みの記事は前編です。) Serverless Architecture 一休 CTO 伊藤直也氏。 先に結論を言ってしまうと、サーバーレスアーキテクチャと

    伊藤直也氏が語る、サーバーレスアーキテクチャの性質を解剖する(前編)。QCon Tokyo 2016
  • Amazon Elasticsearch Serviceを使ったログ収集基盤の構成を考えてみた

    みなさんこんにちは。@ryuzeeです。 6月10日にAmazon Web Services企業導入ガイドブックが発売になっていますのでよろしくお願いします。 さて今回はAWS上でログ収集と分析をする際に、Amazon Elasticsearch Serviceを使う前提とした場合だとどのような構成案がありそうかいくつか考えてみたのでご紹介します。 なお、検討の材料にしている全体の構成としては、複数のVPC(またはAWSアカウント)があって、さらにオンプレ側とDirect ConnectやInternet VPNで接続しているような、よくあるそれなりの規模の構成になります。 各VPCの中には複数のサブネットがあり、そのうちのいくつかはプライベートサブネットに分かれているものとします(個人的にはインターネットゲートウェイの有無しか違いがないので、プライベートサブネットあまり作りたくない)。

    Amazon Elasticsearch Serviceを使ったログ収集基盤の構成を考えてみた
  • [AWS]構成図からAWS環境を自動構築するツール「VisualOps」を触ってみた - Qiita

    こんにちは。 今回は、「VisualOps」という、書いた構成図から自動で構築してくれるツールを触ってみようと思います! これぞクラウド!という感じがして、とてもテンションが上がるツールです。 昔は「Madeiracloud」という名前だったようです。 1.概要 さくっと概要ですが、VisualOpsでは、こんなことができます!!! 構成図描いて... ローンチすると... AWS環境が自動で構築される!!! さらに... 作成した構成図をPNG、JSON、CloudFormation用フォーマットで出力することもできます!! AWSエンジニア経験が浅い私にとっては夢のようなツールです! 2.セットアップ それでは、実際に使っていきます! VisualOpsのアカウントの登録からAWSのアカウントの紐付けまでやっていきます。 1.VisualOps公式サイトに接続し、[SignUpFre

    [AWS]構成図からAWS環境を自動構築するツール「VisualOps」を触ってみた - Qiita
  • 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
  • AWSハイブリッド構成のDNS設計レシピ

    ども、大瀧です。 AWSとオンプレミスのハイブリッド構成は、エンタープライズのAWS活用では定番となりつつあります。そんなAWSハイブリッド構成の設計でよく課題に挙がるのが、DNSです。このブログエントリーでは、使えるDNSサービスの種類とその特性をまとめ、いくつかの構成パターンを解説、比較してみます。 AWSハイブリッド構成とは AWSハイブリッド構成は、AWSでプライベートネットワークを構成するAmazon VPCとオンプレミスのネットワークを相互接続し、両方のサーバーリソースを組み合わせて利用するものです。VPCとオンプレミスとの接続は、プライベート接続として専用線 *1かインターネットVPN *2を利用します。 AWSハイブリッド構成で利用するDNSサービス DNSサーバーには権威サーバーとキャッシュサーバーの2種類がありますので、それぞれで利用できるサービス毎に並べてみました。[

    AWSハイブリッド構成のDNS設計レシピ
  • 【社内資料公開】AWSトラブルシューティングページまとめ/より早い原因把握のために心がけること | DevelopersIO

    はじめに こんにちは植木和樹です。オンプレで10年近くサーバーの保守運用をやっていた経験からいいますと、AWSの障害発生率は非常に低くて驚きます。数百台規模のサーバーを扱ってますと、毎日どこかでのサーバーでディスク、CPUファン、メモリーパリティエラーなんかの故障が起きていて日々対応に駆けまわってた覚えがあります。 さてAWSの障害発生率が低いといってもゼロというわけではありません。仮に0.1%だとしても1000日つまり3年運用していれば1回くらい障害に遭遇するものです。0.01%だったとしてもサーバーが1万台あれば1日1回なにかしらのトラブルに遭遇しても不思議ではありません。 トラブルに遭遇すると、当然サービスや処理に影響をきたしてしまうわけで早期の暫定処置と、その後に恒久的な対策が求められます。その時に重要なのは早く正しく原因を特定することです。トラブルシューティング力が重要です。 A

    【社内資料公開】AWSトラブルシューティングページまとめ/より早い原因把握のために心がけること | DevelopersIO
  • [レポート]ローソンがAWSを使うまでの軌跡~打ち破れ、現行踏襲~ #AWSSummit | DevelopersIO

    こんにちは、城内です。 今回は、 AWS Summit Tokyo 2015のEG-04セッションのレポートです。 セッション情報 セッション名:ローソンAWSを使うまでの軌跡~打ち破れ、現行踏襲~ スピーカー:株式会社ローソン 業務統括部 システム基盤部 マネージャ 進藤広輔氏 AWS利用までのアプローチ 検討の前提 検討の際は加点方式で考える(一般的に減点方式で考える方向にある) 「使える要素を重点的に」 検討よりもまず試す AWSのメリット オンプレではハードウェアの調達がネックだったが、AWSはスピーディーにサーバを構築できるため、とりあえず3か月で試してみるというパターンにフィットする RDSなどマネージドなサービスが選択できる エンタープライズサポートとプロフェッショナルサービスを利用することでいままで苦労していた困難な課題に迅速に対応できた ※AWS検討当初、ポジティブな

    [レポート]ローソンがAWSを使うまでの軌跡~打ち破れ、現行踏襲~ #AWSSummit | DevelopersIO
  • 【Amazon S3 Streaming】AWS CLIを使って標準入出力とS3を直接つなぐ【小ネタ】 | DevelopersIO

    よく訓練されたアップル信者、都元です。ひさびさのブログになってしまいました。リハビリも兼ねて、小ネタにて。 ローカルファイルシステムと標準入出力 まずは基礎的過ぎる話から。linuxシェル上で、ローカルファイルシステム上のファイルを標準出力に書き出したい時、例えばこんなコマンドを使いますね。 $ cat foo.txt 次に、シェルからちょっとしたテキストファイルを作成したいとき、下記のようにechoとリダイレクトを使って書き込みをすることがあると思います。 $ echo foobar >foo.txt 複数行に渡るファイルであれば、ヒアドキュメント *1を使ってこんな感じでしょうか。 $ cat << _EOF_ >bar.txt aaa bbb _EOF_ ローカルファイルシステムとAmazon S3 さて一方で。AWS CLIでは、下記のようにs3 cpサブコマンドで、S3とローカル

    【Amazon S3 Streaming】AWS CLIを使って標準入出力とS3を直接つなぐ【小ネタ】 | DevelopersIO
  • AWSのフルマネージドサービスのみ使ってIoT向けビッグデータ基盤を構築する | DevelopersIO

    はじめに KinesisやRedshiftを使ったビッグデータ基盤の運用負荷を減らせないかと考えていたところ、Lambdaが正式公開されましたのでAWSのフルマネージドサービスだけで構築できないかやってみました。今回、構築したのはスマホアプリやIntel Edisonなどの端末からセンサー情報をKinesisに送信後、S3を経由してRedshiftにデータをロードするところまでになります。処理としては以下の図のような流れになります。Kinesisにデータを送信する箇所とデータ分析の部分は含まれていません。今回まだLambdaが東京リージョンでは使えないので、N.Virginiaリージョンで試しました。 Kinesisから取得したデータをCSVにしてS3へアップロードする デバイスからKinesisに送信されたデータを取得してCSVファイルを作成、S3にアップロードしています。 準備する K

    AWSのフルマネージドサービスのみ使ってIoT向けビッグデータ基盤を構築する | DevelopersIO
  • AWS(Amazon Web Services)技術資料メモ(2015年3月版) - hiroshixの日記

    2015-03-16 AWS(Amazon Web Services)技術資料メモ(2015年3月版) 2015年3月版に更新。 技術資料はココにあるんだけど、散らかってるのでまとめてみた。全体的に資料の日付をチェックした方がいいかも。資料公開からアップデートがある場合も。あとどの資料も最初に概要入っててごめんなさい。 概要的なやつ スタートアップならおさえておきたいAWS入門サービス概要と基礎知識編 スタートアップならおさえておきたいAWS入門サービス概要と基礎知識編 from Hiroshi Takayama →つまづきやすいポイントや不安点など WebサービスStartUP向け AWSスケーラブルな構成例 WebサービスStartUP向け AWSスケーラブルな構成例 from Amazon Web Services Japan →構成例・代表的なサービスの一言紹介・課金関連・サポ

    AWS(Amazon Web Services)技術資料メモ(2015年3月版) - hiroshixの日記
  • AWSで構築した環境にありがちなシェルスクリプトたち まとめ | DevelopersIO

    AWSでサーバを運用する際にはEC2からAWS CLIを使って他のAWSのサービスと連携したりすることがあると思いますが、AWS環境ならではのシェルスクリプトを集めてみました。AWS CLIのバージョンは1.7.13、Pythonのバージョンは2.6.9を使っています。私はAmazon Linuxで動作を確認しています。 目次 準備する AWS CLIのインストール AWS CLIのアップデート aws configureでセットアップする IAM roles for EC2 instancesに関して 監視系 CloudWatchでカスタムメトリクスを設定する ZabbixからCloudWatchの値を取得する プロセス監視する バックアップ系 AMIとEBSのバックアップを作成する RDSのスナップショットを作成する S3のフォルダを削除する 便利スクリプト系 Route53の自動登録

    AWSで構築した環境にありがちなシェルスクリプトたち まとめ | DevelopersIO
  • AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05

    AWS Black Belt Online Seminar 2018 Amazon DynamoDB Advanced Design PatternAmazon Web Services Japan

    AWSにおけるバッチ処理の ベストプラクティス - Developers.IO Meetup 05
  • Amazon Redshiftへのデータ投入からBIツールによる可視化までの手順

    データの入手、整形 Amazon S3へのデータのアップロード Amazon Redshift:テーブルの作成 Amazon Redshift:データの投入 Amazon Redshift:SQLによるバッチ処理(ETL) BIツールからの接続確認 また、利用するBIツールはTableau社が提供している『Tableau Desktop』というデスクトップツールを利用したいと思います。文中『Tableau』という言葉が出て来た際はこの『Tableau Desktop』のことを示しているとご理解ください。 データの入手・整形 では分析を行いたいデータを準備するところから見ていきましょう。Tableau社では各種デモで用いることができるようなサンプルデータを公開していますが、今回はそのサンプルデータを利用したいと思います。 以下のリンクで公開されているものは、架空の店舗別・地域別売り上げデータ

    Amazon Redshiftへのデータ投入からBIツールによる可視化までの手順
  • AWS SDK for PHP のパフォーマンスを改善するたった3つのこと - Qiita

    いずれも、ほとんどコードに手を加えることなくできる改善なので、SDKを利用しているなら、すぐにでもやるべきだ。 もし、これから開発をはじめようとしているなら、前提としてまず、 PHP5.6 もしくは PHP5.5 を使うことをオススメする。 もちろん、PHPのバージョン関係なく以下は有用なものです。 1. Composer の classmap autoloader を使う

    AWS SDK for PHP のパフォーマンスを改善するたった3つのこと - Qiita
  • AWSのアカウント管理の話 - プログラマでありたい

    AWS Advent Calendar 2014の7日目です。あと、全部俺Advent Calendarも開催中です。 運用絡みで何か書くと宣言したので、AWSのアカウント運用について書いてみます。テクニックや技術より、考え方の面での整理です。 AWSのアカウントの種類 AWSで利用するアカウントは2種類あります。AWSアカウントとIAMアカウントです。AWSアカウントは、マスターアカウントと呼ぶこともあって大元のアカウントになります。AWSにサインアップ時に作るものが、AWSアカウントで1つだけ存在します。それに対して、IAMアカウントはユーザアカウントです。AWSの管理コンソールから、個々のユーザ向けなどに作成します。 AWSアカウントの取扱について AWSアカウントは、全権限を持っています。強力すぎるアカウントで、日常の運用に利用するには危険すぎます。日常の運用には使わないというのが

    AWSのアカウント管理の話 - プログラマでありたい
  • 実践!ヌーラボサービスでの CloudFront の障害対策 | 株式会社ヌーラボ(Nulab inc.)

    CDNが単一障害点にならないようにするために ヌーラボでは 2010 年 Cacoo の商用サービスの開始に合わせて AWS における運用を開始しました。当時、運用環境として AWS を採択する決め手の一つになったのが CloudFront でした。その後も着々とエッジロケーションは増え、独自ドメインのサポートなど魅力的な機能も提供され、今ではヌーラボの全サービスの静的ファイルの配信で利用している、無くてはならないサービスとなっています。 その魅力の反面、CloudFront の障害は、アプリケーションそのものに問題がなくても、以下のような表示が崩れた画面が表示されて、ユーザが全くサービスを使えなくなるという、その影響が非常に大きいものです。また障害の原因が DNS やネットワークの経路における問題といった、私たちが直接解決しにくい領域にあることもしばしばです。 ただ、どんな事情であれ、障

    実践!ヌーラボサービスでの CloudFront の障害対策 | 株式会社ヌーラボ(Nulab inc.)
  • Amazon CloudFront の障害に備えてフェイルオーバーを設定する - Qiita

    時間 2014/11/27 の AM9時〜AM11時頃まで、全世界的に Amazon CloudFront に障害がありました。 CDNとして CloudFront を利用しつつ、障害時にはフェイルオーバーする方法をまとめました。 S3 CloudFrontのOriginがS3でない場合は、この項の設定は関係ありません。 CloudFrontのOriginとしてS3を使う場合、以下のようにします。 file.example.jp のような、使いたいドメイン名で S3バケット を作る Static Website Hosting を有効にしておく ドメイン名のバケットで Static Website Hosting が有効になっていないと、後述の Route53 の Alias Target に設定できません。 Health Check Route53 の Health Checks を

    Amazon CloudFront の障害に備えてフェイルオーバーを設定する - Qiita
  • AWS CodeDeploy + Travis CI でデプロイを自動化する | DevelopersIO

    Travis CI が AWS CodeDeploy をサポート AWS CodeDeploy (以下、CodeDeploy) で遊びまくっている者です。 CodeDeploy の肝は、何と言っても自動化でしょう!自動化といえば、CI サービスである Travis CI は既に CodeDeploy をサポートしています。Travis CI を既に使っている人は、少々設定を加えるだけで簡単に CodeDeploy のデプロイ処理を追加できます。 ということで今回は Travis CI 経由で CodeDeploy のデプロイ処理を実行してみたいと思います! デプロイを自動化してみる 事前準備 まず、Travis から CodeDeploy を実行するため、IAM User を作成しましょう。デプロイが実行できるよう、次のようなパーミッションにします。 { "Version": "2012-

    AWS CodeDeploy + Travis CI でデプロイを自動化する | DevelopersIO
  • AWSでSESと無料のSQSを使って快適なメールマガジン配信システムを構築した話 - ぷれすとぶろぐ

    Amazon Web ServiceでSESとSQSを使って、大量に高速に送ることが出来るメールマガジン配信システムを構築してみました。 もともと、別の開発者の人が開発していたものを、引き継いで受託していたサービスが、日々会員数が増えるたびにメールの配信時間が伸びていき、最終的に2万人に配信するのに6時間ほどかかるシステムになっていました。 システム システム構成はシンプルでAWSのEC2のインスタンス上でDBやアプリケーションが動いており、画像などのリソースの保存にS3を、メール送信にSESを使っています。 ちなみにアプリケーションはJavaEEです。最近ではちょっと珍しい?ですね。 問題点 もともとのシステムは、管理画面から登録されたメルマガ情報からメルマガを受診する対象のユーザーを取得し、名前などを埋め込んだスプールを作成する「スプール生成バッチ」と、DBに登録されたスプールを順番に

    AWSでSESと無料のSQSを使って快適なメールマガジン配信システムを構築した話 - ぷれすとぶろぐ