AWS SAMとServerless Frameworkを比較してみた - Qiita
この記事はServerless Advent Calendar 2017 ２３日目の記事です。 最近Serverless Frameworkを使っていたのですが、先輩に「今の時代はAWS SAMだぞ」と言われ、気になったので比べてみました。 Serveless Frameworkの特徴 デプロイしやすい・速い まずこれが一番の特徴ですね。 下記の例みたいにたったコマンド２つですぐ動かせるサーバーレスアプリケーションが出来上がります。 もし↑と同じことSAMでやろうとした場合： リリースステージ用のバケットの作成 Lambda関数のコーディング 設定ファイルを書く Lambda関数のzip化 Cloudformationによるパッケージング これらの作業を全て自分でやらなければなりません。 Serverless Frameworkを使うとこういったデプロイ前の準備作業をよしなにやってくれます
AWS上で動作するアプリケーションをいかにローカルで開発するか？ - たけぞう瀕死ブログ
AWSでは様々な便利なサービスが提供されています。中にはRDSやElasticCacheのように既存のミドルウェアに対するマネージドサービスを提供するものもあり、これらについては既存のミドルウェアを使って開発することができますが、AWS固有のサービスについてはアプリケーションを動作させるには実際にサービスに接続する必要があり、開発環境が制限されてしまいます。 もちろんソフトウェア側で抽象化しておき、DIなどの手法を用いてモックに差し替えるという方法も考えられますが、特にストレージとして利用するサービスなどの場合はインタラクションが必要になるのでモックでは再現しづらいですし、やはり実際に動作するサービスに接続して開発やテストを行うほうが効率的です。 そこで、AWSのサービスを擬似的にローカルで再現することのできるプロダクトを集めてみました。 S3 node.jsで動作するs3-proxyが使
AWS ec2 t2タイプには51300コネクションしか繋がらない - Qiita
2017/6/26追記 すみません。追試をしたら51300での限界が確認できたのはt2.mediumまででした。ただし、t2.largeでも約8万の限界があるようです。4章、5章を修正しました。 2017/6/27追記 Developer Forums（米）に質問をしたところ、原因不明だがm4シリーズでも10万以上で限界値を確認したという報告がありました。どうもAWS特有のアンドキュメントな現象らしいとのこと。 この記事ではAWS ec2上のCentOS7にインストールしたGo1.8を使っています。 AWS ec2のt2タイプには51300コネクションしか繋がらないようです。どのドキュメントを見てもこのような仕様は書かれていません。原因は不明でしたが、事実関係を集めたいので、同意非同意によらずに広くコメントいただきたいです。 いろいろ切り分けを繰り返したので、「CentOS7での大規模サー
AWS News Blog
New — File Release for Amazon FSx for Lustre Amazon FSx for Lustre provides fully managed shared storage with the scalability and high performance of the open-source Lustre file systems to support your Linux-based workloads. FSx for Lustre is for workloads where storage speed and throughput matter. This is because FSx for Lustre helps you avoid storage bottlenecks, increase utilization of compute
AWS Database Migration Serviceを使って水平分割されたDBの縮退に挑戦した話 - Qiita
概要 AWS Database Migration Service 略称DMSを使って、水平分割されたDBインスタンスを縮退しようと計画していましたが、検証中に不具合らしきものを見つけたので中断しました。この記事はDMSを検証中に引っかかったトラブルや対策について書いていたメモをまとめたものです。今回の記事中で説明する内容は実環境からぼかしている箇所がありますがご容赦ください。 ※ この文章での「メンテナンス」という単語は、ゲームシステムのメンテナンスを指しており、AWS側のメンテナンスとは異なります。 動機 通常DBは基本的にはスペックが不足したらスケールアップを行い対応します。弊社では加えてより大規模な負荷でも耐えられるよう水平分割してスケールアウトも併用する構成になっております。規模の拡大時には問題無いのですが、必要とされる負荷が下がった場合や、サービスの使われ方が変わって別のサブシ
Aurora のパラメータグループで max_connections の値が計算値と合わない - kakakakakku blog
最近 Aurora の検証をしているので，今後は Aurora 関連の記事を書く機会が増えそう． 前提 RDS (Aurora MySQL) インスタンスタイプ : db.t2.medium DBInstanceClassMemory とは RDS のパラメータグループでは，特定の変数と演算子を使った動的な値設定ができる．今回は変数 DBInstanceClassMemory に関して調べたことと，計算が合わずに困ったことを書いておこうと思う． DBInstanceClassMemory は，名前だけを見るとインスタンスタイプごとに搭載されたメモリサイズのように思えるけど，実際には違っていて，RDS プロセスに割り当てられたメモリサイズのことを意味する．よって，搭載されたメモリサイズよりは確実に小さい値となる．その点はドキュメントにも書いてある． DBInstanceClassMemory
EC2 Auto-ScalingでECS組んでますか？エラーレート高いですか？救ってあげてもいいですか？ | CyberAgent Developers Blog
EC2 Auto-ScalingでECS組んでますか？エラーレート高いですか？救ってあげてもいいですか？ サイバーエージェント技術本部インフラエンジニアの@prog893です。今回も「AWA」という音楽ストリーミングサービスのインフラの改善について紹介したいと思います。前回の記事では、データベースの復旧時間が12時間から55分まで短縮できた話を紹介しましたが、今回は楽曲ダウンロード及びストリーミングレイヤーでのエラー率を大幅に改善したことについて述べたいと思います。 楽曲ダウンロード及びストリーミングの構成 まず、楽曲ダウンロード及びストリーミングの構成概要について紹介します。 音楽ダウンロード及びストリーミングの構成概要 楽曲配信サーバ(以降Track Proxy)はコンテナとして実行しAWS Elastic Container Service（ECS）で運用しており、ECSのバックエン
GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！ - Qiita
🤔 前書き 稀によくある 、AWS を不正利用されちゃう話、 AWSで不正利用され80000ドルの請求が来た話 - Qiita 初心者がAWSでミスって不正利用されて$6,000請求、泣きそうになったお話。 - Qiita AWSが不正利用され300万円の請求が届いてから免除までの一部始終 - Qiita ブコメ等で GitHub にはアクセスキーを検索するBOTが常に動いていて、公開するとすぐに抜かれて不正利用される 的なコメントがつくのを何度か目にしたのですが、 本当にそんな BOT が動いているの？ どのくらいの時間でキーを抜かれて、不正利用が始まるの？ というのが気になったので、検証してみました。 GitHub にそれっぽいパブリックリポジトリを作成、権限が一つもついてない AWS のアクセスキー＆シークレットアクセスキーをうっかり公開、外部から利用されるまでの時間を計測します。
DBが真っ白になっても55分で完全復旧ができるまでの道 | CyberAgent Developers Blog
初めまして。サイバーエージェント技術本部インフラエンジニアの@prog893です。今回は「AWA」という音楽ストリーミングサービスのMongoDBクラスタの復旧時間を短縮するために行ったインフラの改善について紹介したいと思います。復旧時間が12時間から55分まで短縮できたのですが、皆さんの参考になれば幸いです。（※注意：今回紹介する施策はAWAのインフラ構成や設定のものであり、他の環境で同じような効果が得られるとは限りません） AWAのデータストア構成 まず、現在のデータストア構成について軽く説明します。こちらの図でAPIサーバ，MongoDBに関連する構成の概要を示します： AWAのデータストア構成概要 メインのデータストアとしてはMongoDBを使っており、MongoDBのインスタンスはAWSで管理しています。APIサーバ、MongoDBのインスタンスがそれぞれのプライベートサブネット
東京リージョンに新たにアベイラビリティゾーンを追加 | Amazon Web Services
Amazon Web Services ブログ 東京リージョンに新たにアベイラビリティゾーンを追加 本日 東京リージョンにて、新たにアベイラビリティゾーンを追加しました。東京リージョンは、追加のアベイラビリティゾーンを合わせ、4つのアベイラビリティゾーンになりました。 AWSは、世界中に18の物理的なリージョンと51のアベイラビリティゾーンがあります。本日追加されたアベイラビリティゾーンは、シンガポールリージョンに続き52番目となり、東京リージョンでAWSのクラウドコンピューティングをご利用の10万以上のお客さまにご利用いただけます。 アベイラビリティゾーンは、自然災害やデータセンター単位の障害などビジネスに影響を与えるリスクを最小化するよう地理的に影響を受けない十分離れた場所にあり、フェイルオーバーを実現し事業継続性を確保できるインフラストラクチャです。各アベイラビリティゾーンは、独立し
AWSもSpectreとMeltdownの対策完了を報告。対策後、Amazon EC2で性能の低下は見られないと
Amazon Web Services（AWS）は、「Spectre」および「Meltdown」と名付けられたCPUの脆弱性に関して同社の対応をまとめたWebページ「Processor Speculative Execution Research Disclosure」において、すでに脆弱性対策が済んだことを報告しています。 AWSがこうした特設ページを設けるのは珍しいことで、本件の重要性と緊急性の高さがうかがえます。 ただ、Googleが脆弱性の詳細な報告と対策の経緯などを詳細にブログで開示したのに対し、AWSの情報提供は実務的であっさりしたものになっています。 Amazon EC2のワークロードに性能低下は見られない 下記はAmazon EC2に関する報告を引用したものです。すべての対策が済んだと報告されています。また、OSのアップデートが推奨されています。 All instances
Amazon EC2 Instance Comparison
API Name Instance Memory Compute Units (ECU) vCPUs GiB of Memory per vCPU GPUs GPU model GPU memory CUDA Compute Capability FPGAs ECU per vCPU Physical Processor Clock Speed(GHz) Intel AVX Intel AVX2 Intel AVX-512 Intel Turbo Instance Storage Instance Storage: already warmed-up Instance Storage: SSD TRIM Support Arch Network Performance EBS Optimized: Baseline Bandwidth EBS Optimized: Baseline Thr
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適用したりなどなどセールストー
AWSが米国で起こした二度目の「CIAショック」
金融業を含む民間企業が業務システムをパブリッククラウドサービスの「Amazon Web Services（AWS）」で運用するのは、日本でも既に当たり前になった。日本の先を行く米国では、政府機関の業務システムのAWS移行が加速し始めている。 AWSの活用に積極的な姿勢を見せる米政府機関の一つが米中央情報局（CIA）だ。CIAは米Amazon Web Servicesが2017年11月20日（米国時間）に発表した米国の情報機関専用のリージョン（データセンター群）である「Secret Region」を利用する意向を示している。 AWSは2011年8月に、米政府機関用リージョン「GovCloud」の運用を米国西海岸で開始した。米政府のセキュリティ規制に対応し、司法当局が身元確認をした米国人のみがシステムの運用に関わるというリージョンだ。情報機関専用リージョンである「Secret Region」は
AWSの新サービス群に対する一行所感 - プログラマでありたい
今年もラスベガスで、AWSの最大のイベントre:Invent開催中です。初回のキーノートが終わった所ですが、怒涛のサービス発表で頭が混乱中です。整理のために、サービスに対する感想をつけてみます。間違っているかもしれないので、悪しからず。 AWS AppSync モバイル等での複数端末のデータ同期を見据えたソリューション。必要性はすごく解るが、それってCognito Syncでやりたかったことじゃないのかな？認証認可のサービスにデータ同期を加えた筋の悪さを解消に来たのか？ 2017/12/3 追記 中の人曰く、次のような役割分担とのこと AWSの新サービス群に対する一行所感 - プログラマでありたい ありがたし / Cognito Syncは「一つのIdentityに（≒一人の人間）が持つ」複数端末間での設定値等の同期のためのものだったので、前提と志向が違うのです > AppSync “それ
タスクIAMロールとパラメータストアを利用したAmazon ECSアプリケーションの秘密情報管理 | Amazon Web Services ブログ
Amazon Web Services ブログ タスクIAMロールとパラメータストアを利用したAmazon ECSアプリケーションの秘密情報管理 同僚のStas Vonholskyが、Amazon ECSアプリケーションの秘密情報管理に関する素晴らしいブログを寄稿してくれました。 —– コンテナ化されたアプリケーションとマイクロサービス指向のアーキテクチャが普及するにつれて、アプリケーションデータベースにアクセスするためのパスワードなどの秘密情報を管理することは、より困難かつ重要になっています。 いくつか課題の例を挙げます： dev、test、prodなどのさまざまなアクセスパターンをコンテナ環境全体でサポートしたい ホストレベルではなくコンテナ/アプリケーションレベルで秘密情報へのアクセスを隔離したい サービスとしても、他サービスのクライアントとしても、アクセスが必要である疎結合なサービ
サーバレスアーキテクチャによる時系列データベースの構築と監視 / Serverlessconf Tokyo 2017
サーバレスアーキテクチャによる時系列データベースの構築と監視
Microsoft Word - final aurora sigmod sgm162id mar 28.docx
Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases Alexandre Verbitski, Anurag Gupta, Debanjan Saha, Murali Brahmadesam, Kamal Gupta, Raman Mittal, Sailesh Krishnamurthy, Sandor Maurice, Tengiz Kharatishvili, Xiaofeng Bao Amazon Web Services ABSTRACT Amazon Aurora is a relational database service for OLTP workloads offered as part of Amazon Web Services (AWS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「サル軍団」にシステム障害を起こさせる、Netflixの驚異的なトラブル撲滅法
AWS費用と戦う
