Alternative Architecture DOJO Offline #3での資料です。
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか?ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か?と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか?というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
はじめに 以前、AWS利用料のメールが見て、思っていたよりも高くてビックリしたことがあります。調べてみたところ勉強用に立ち上げたRDSを消し忘れていました。今は会社のアカウントを使わせてもらっているので自分の財布に直接響くことはなくなりましたが、同じことを起こさないために消し忘れたリソースがないか自動でチェックするようにしています。私が使っているツールを紹介します。 お使いの開発環境などで無駄なリソースが残っていないかチェックしてみてください。 チェックしたい主なリソース EC2 まずはEC2インスタンスですね。説明は不要だと思います。 Amazon EC2 料金表 EC2を停止していてもEBSの料金が発生します。ストレージはあまり気にされてない方多いと思いますが、数が多いと結構金額膨らむので注意しましょう。例えば20GBのEBSが10台あると1か月間で24ドルほどかかります。 Amazo
はじめに こんにちは、平野です。 AWS Lambdaがやっと使えるようになってきました。 私は新しい物事を理解しようと思った時、 「できるだけ最小限な構成から少しずつ要素を増やしていって、 そこから挙動を類推して確かめる」 というような調べ方でないとどうにも腑に落ちない性格のようなので、 そんな感じでLambdaも試行錯誤してみました。 Lambdaについては前から面白そうだと思いつつもなかなか手を出せずにいました。 事前の知識としては「あるイベントが起きたら、何らかのイベントを起こすもの」 ぐらいのふわっとした理解しかありませんでしたが、 私と同じ辺りの出発点からスタートする人の参考になればと思います。 最小限でLambdaを構成する ということで、できるだけ最小限の構成でLambdaを動かしてみます。 作るもの 以下のような動作で検証を行います。 究極的に最小限というわけでは無いです
やりたいこと(ユースケース)から利用パターンへ到達できるように、ユースケース主導で紹介。利用するサービスのすべての機能をを覚えなくてもやりたいこと/部分からスタートできます。実際、類似するアーキテクチャの実例が多くあることがわかります。 パターン別のテンプレートから始めてみよう! チュートリアルで体感しよう! - いくつかのパターンはテンプレート/雛形から始めることができます。それぞれのパターンの「Template」「Sample」「Solution」のリンク先を参照ください。 - 実際に作って動かせるチュートリアルに「Tutorial」「Workshop」リンクからアクセスできます。ちょっとしたトライに費用が気にならないのもサーバーレスの良いところ。 - 各パターンの特性に合わせたエラーハンドリングの記事を拡充中。それぞれのパターンの「エラーハンドリング」リンクからご確認ください。 -
概要 作ったもの 最近お金が減るのが早くなった気がしたので、家計簿をつけようと思い立ちました。アプリをダウンロードしてきてもよいのですが、せっかくなので自分で作ることにしました。 タブレット、スマホ、パソコンのどれでも見れるようレスポンシブ対応を行ったのですが、タブレット(iPad)からみると以下の画像のようなものになっています。 チャート画面 記入画面 取引一覧画面 構成 静的ファイルはAWSのS3にホスティングし、お金のやり取りに関する情報はRDSに貯め、情報の追加・削除・修正にはLambdaとAPI Gatewayを用いて作ったAPIを通して行います。LambdaのコードはPythonで書いています。 簡単な図にすると、以下の画像のようになります。 共通部分 フロントエンド フロントはVue.jsを使って実装します。以下の画像の赤枠で囲った部分に表示するコンポーネントを切り替えます(
事前準備 下記の設定を行います。 AWS請求の設定 Slackの設定 AWS請求の設定 ルートアカウントでログインし、設定画面から「コストエクスプローラ」を有効にします。 Slackの設定 チャンネルの作成 通知先のチャンネルを作成します。ここでは、チャンネル名を#aws-billingとしています。 Incoming Webhookの追加 Incoming Webhookの設定を行います。 通知先チャンネルから「アプリを追加する」を選択します。 アプリとしてIncoming Webhookを検索します。 「設定を追加」を選択します。初回であれば画面は違うかもしれません。 投稿先のチャンネルを選択し、「incomming Webhookインテグレーションの追加」を選択します。 作成されたWebhook URLをメモしておきます。このURLに対して、特定フォーマットでPOSTすれば、Slac
AWS Lambda互換環境をKubernetes上で実現する「Knative Lambda Runtime」オープンソースで公開 TriggerMeshは、Kubernetes上にAWS Lambda互換の実行環境を構築することで、AWS Lambdaで利用可能なファンクションをそのままKubernetes上で実行可能にする「Knative Lambda Runtime」(KLR:発音はClear、クリア)をオープンソースで公開しました。 Announcing TriggerMesh Knative Lambda Runtime (KLR) https://t.co/2BOINQUbys pic.twitter.com/kycNdlWhoK — triggermesh (@triggermesh) 2019年1月9日 Knative Lambda Runtimeを公開したTriggerM
Udemyのセールで購入した下記の講座が大変良かったので、紹介するとともに学び直した内容の備忘録を残しておくことにした。なのでこの記事で特定のAWSの機能の設定の仕方などは書いてはいない。Linuxの基本的なことはわかっている人がAWSを体系的にどうやって学んだのか、どういう理解の仕方をしたのかを知ることができるという内容だ。 手を動かしながら2週間で学ぶ AWS 基本から応用まで 作者の方の紹介ページ www.ketancho.net こちらの副読本とした。 比較的新しい本であり上記の作者の方も作者に名を連ねているところから、用語の説明の仕方などにUdemyの講座とブレが少なく理解しやすそうなのでこちらを選んだ Amazon Web Services パターン別構築・運用ガイド 改訂第2版 (Informatics&IDEA) 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西
2019/4/30を持ちまして本講座の新規受付を停止いたしました!1万人を超える方に受講していただきました。「参考になった」「業務や転職に役立った」というお声をたくさんいただき、講座を作ってよかったと思っています。今後も技術的な話をしていければと思いますので、もしよろしければ今後もブログやTwitterをフォローいただければと思います。 twitter.com Udemy で AWS の講座を持たせていただくことになりました!タイトルは「手を動かしながら2週間で学ぶ AWS 基本から応用まで」です。この記事ではこの講座の特徴についてご紹介したいと思います。記事の最後に、お得に講座を受講できるクーポン情報を載せておりますので、ぜひ最後までご覧いただければ嬉しいです。 https://www.udemy.com/aws-14days/www.udemy.com 講座を作るに至った経緯 Udem
2018年8月30日、クラウドストレージサービス「Dropbox」を展開するDropbox Japanは、グローバルのストレージインフラやネットワークについての説明会を実施。AWSにあったシステムを自社データセンターに移した背景やそのメリットなどをDropbox Japanの保坂大輔氏が説明した。 エクサバイトに向け加速度に増え続ける超巨大システム Dropboxを支えるテクノロジーについて説明した保坂氏は、まずDropboxのサービスのスケール感について説明した。Dropboxが展開されている国は現在180以上で、登録ユーザー数も5億人以上になる。このうち1100万におよぶ有料ユーザーの80%以上はDropboxを業務で利用しており、個人向けサービスのイメージからは脱却しつつある。実際、日本でも関西大学やアディダスなどが万単位のアカウント数で運用しているという。 顧客データも1エクサバイ
はじめに AWSの費用見積をする際におさえておいたほうがよいポイントについて説明します。 従量課金制である AWSのほとんどのリソースは1時間毎、もしくは利用量毎の課金です。 従量課金制の一番よいところは、ずっと使い続けなくてよいというところです(あたりまえですが)。 急なイベントの時にだけリソース増強 (弊社のこの事例はまさにそれです) 検証環境は必要な時に本番環境から作成 という使い方をすることで費用削減が可能です。 実際の必要リソースがわからない部分については、リソース大目の環境を作って検証して、結果的に不必要であればその時点でインスタンスを小さく/大きくする等で対応できます。 最初の見積がずれていても、ずっとそのコストを払わなくてもよい点、頭の片隅のおいておいてください。 また、AWSならではの従量課金の項目もあります。 EBS(ネットワークストレージ)のI/O ネットワークの通信
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く