AWS Well-Architected
AWS Well-Architected アーキテクチャのベストプラクティスを使って、学習、測定、構築を行う AWS Well-Architected は、クラウドアーキテクトがさまざまなアプリケーションやワークロード向けに安全性、高い性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。AWS Well-Architected では、6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいて、お客様とパートナーがアーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチを提供しています。 AWS Well-Architected フレームワークには、ドメイン固有のレンズ、ハンズオンラボ、AWS Well-Architected Tool が含まれています。追加コストなしで AWS マネジメントコ
紙面ビューアーを支える サーバーレスアーキテクチャ / serverless architecture supports Nikkei's paper viewer
RDS ReadReplicaを立てて、参照クエリを逃がすことを考える。 可用性や拡張性を考えてReadReplicaは複数台構成とした場合、RDSの仕様を考慮して設計しておく必要がある。ポイントは以下。 Read Replicaは個々にEndpoint (DNS名) を持つ。 複数Read Replicaに対してバランシングする仕組みは提供していない。 ELBは RDS (Read Replica含め) には使えない。ELBにぶら下げられるのはEC2のみ。 Read Replica各ノードの死活監視、障害時の切り離し／切り戻しを考慮する必要がある。 ということで、Read Replicaのバランシングを行うなら、自分で仕組みを用意する必要がある。 実現方法はいくつか選択肢があるが、今回はL7のバランサーとして定評のあるHAProxyを使ってみる。 Architecture with HA
AWS Case Study: Amazon.com Oracle DB Backup to Amazon S3
SOLUTIONS Customer Success Stories Discover how customers across industries increase agility, optimize costs, and accelerate innovation using AWS Experian accelerates .NET modernization using AWS Transform to upgrade seven legacy applications to .NET 8.0, achieving 40% reduction in developer effort and saving 300 engineering days. The global data and technology company automated 687,600 lines of c
こんにちは、@Keisuke69 です。 ポエムです。 クラウドネイティブとサーバレスアーキテクチャと言うものに関してなんとなく整理がてら書きたいなーと思って。 ま、この2つを一緒に話すのはどうなんだって気もするがポエムなので気にしない。あと文章長い割りに大して中身はない。 クラウドネイティブ そもそもクラウドネイティブとはなんなのか。クラウドネイティブって言葉が先行していて実際のところなんなのか分からない人も多いはず。何かきちんとした単語の定義があるかっていうともちろんそんなのあるわけない。人それぞれモヤっとしたイメージがきっとあってそれを一言で表現するのにクラウドネイティブってキーワードが使われてるのかなと。ラベリング重要。 とはいえ、クラウドネイティブというお題で僕が話をするときに毎回最初に定義をしていて、その定義は以下の通りだ。 クラウドで提供されるサービス利用を前提に構築するシス
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のプラットフォームの役割は、印象深く、分か
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
こんにちは、 VOYAGE GROUP エンジニアブログ Advent Calendar 2013 の2日目担当の @s_tajima です。 僕は今インフラエンジニアとして働いているのですが、 障害が発生すると携帯にアラートメールや電話がとんできて対応を迫られます。 そして障害というのはたいてい楽しいイベントが行われているときに発生するものです。 そういうものと割り切ってせっせと対応をするのもよいのですが、 僕は年末の楽しいイベントを邪魔されたくありません。 それはもちろんAWSの東京リージョンのデータセンターがすべて同時に火事でなくなってしまうような非常事態でもです。 ということで今日はAWSのリージョン間自動DR構成をつくってみた話をしようと思います。 今回のDR構成を構築する上で、カギとなるAWSの機能は以下の3つです。 Route53のELBに対するDNS FailOver ht
Amazon Web Serviceのエバンジェリスト 玉川憲氏は、先週開催されたイベント「JAWS Summit 2012」の「AWSクラウドデザインパターン」（略称CDP）を紹介するセッションで、「シナリオに沿ってデザインを適用していく、ということを考えていく中で大事な原則に気がついた」と話しています。 その大事な原則をまとめたものが「クラウドアーキテクティング原則」です。 玉川氏はセッションの中でそれぞれの原則について口頭で説明しています。ここではその内容をまとめてみました。 できるだけ既存のサービスを利用する 例えばAmazon S3というクラウドストレージのサービス。これは耐久性が高くて便利なオブジェクトストレージなので、Amazon EC2を使って似たような機能を実装するよりもS3を使った方がいい。キューイングも、Amazon SQSというサービスがあるので、自分で実装するより
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
