Alternative Architecture DOJO Offline #3での資料です。
AWS認定のおすすめ参考書ラインナップ。仕上がってるよ!仕上がってるよ! サービスの数もどんどん増えてチョモランマ! ナイス復旧! サーバーが喜んでるよ! ……じゃなかった、パブリッククラウドの中でもMicrosoft Azure, Google Cloud Platform(GCP)と並び3強、シェア的にも世界一を走っている老舗Amazon Web Services(AWS)。2019/8/23には東京リージョンで障害が発生したことでも話題になりました。(関わりのあった皆様お疲れ様です) www.itmedia.co.jp その下にはアジアから食い込んできたAlibaba Cloud、ビッグ・ブルーのIBM Cloudがつき、この合計5サービスが最近での世界TOP5となるそうですね。 さて丁度いま入門していることもあり、このエントリでは最近出揃ってきたAWS認定の資格対策本の紹介をしたい
はじめに 皆さまがシステムを運用にするあたり、様々な不安を抱えていらっしゃると思います。 そういったよくある「不安」を書き出し、解消するための対策や参考ページなども記載しましたので、本記事をご覧いただいている皆さまには抱えている不安を淡々と潰していただければと思います。 【ケース1】大量のアクセスによる高負荷への不安 近日中に Web サイトの広告を出す予定だが、現状のままで増加するアクセスに対応できるのか不安がある 以下のような対策が考えられます ELB(Elastic Load Balancing)を使用し、Webサーバー(Amazon EC2)の複数台構成にする アクセス数や負荷に応じて自動で Webサーバー(Amazon EC2)の台数を増やす(スケールアウト)、減らす(スケールイン)ために AWS Auto Scaling を使用する ELB の暖機申請(予め AWS へ連絡して
Amazon Elasticsearch Serviceに引き続き、AWS Lambdaに入門しました。Lambdaを使って、Amazon Elasticsearch Serviceで特定の単語を検索をさせてslackに書き込んでくれるbot君を練習台でやってみました。 やりたいこと 準備: 適切なポリシーを設定する Goで書いたプログラムをapexを使いAWS Lambdaに転送 Lambda上からAmazon Elasticsearch Serviceで検索 MackerelのAWS連携でLambdaを監視 まとめ やりたいこと AWS強化月間(?)ということでAmazon Elasticsearch Serviceに入門していました。 自宅のElasticsearchとKibanaをAmazon Elasticsearch Serviceに引越し - yasuhisa’s blog
Immutable (不変な) Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。 クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。 背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S
SA岩永です。クラウド時代になり、Blue/Greenデプロイと呼ばれる方式を取るシステムが増えてきました。ただ、日本語で書かれているBlue/Greenデプロイの情報は多少古いものが多いため、特にクラウドで真価を発揮するBlue/Greenデプロイについて2015年の最後に一度まとめてみたいと思います。 以下は私の個人的な考えに基づくものであり、他にも様々な考え方があります。AWSのデプロイに関する発表でも沢山の考え方が提案されていますし、デプロイをサポートするサービスを多種多様に提供しています。1つの考え方として参考にして頂ければ幸いです。 なおこの記事は、2015年のAWS re:Inventのセッション『(DVO401) Deep Dive into Blue/Green Deployments on AWS』を参考にしています。興味のある方はSlideshareやYoutubeを
[速報]Amazonクラウド、大容量データを物理ストレージで配達する「Amazon Snowball」、2016年内に東京リージョンでも利用可能に。AWS Summit 2016 Chicago Amazon Web Servicesは米シカゴでイベント「AWS Summit Chicago 2016」を開催。1日目の基調講演で、Amazon Snowballを2016年内に世界中のすべてのリージョンで利用可能にすると発表されました。 Amazon Snowballとは、2015年10月に発表されたデバイス。 防水かつ8.5Gの衝撃に耐える頑丈なケース内に50テラバイトのストレージを内蔵し、大容量データをネットワーク回線ではなく、ストレージに保存して物理的に輸送することで、ネットワークを使うよりも高速かつ安価、安全にデータ転送を行えます。
はじめに Slack用ボットの定番は Heroku+Hubot だと思いますが、 もっと簡単、シンプルに よりElastic (負荷の増減に柔軟)に かつ、低予算 (サーバーレス) で 運用したいので、AWS Lambda 上に、ライブラリ(Hubot)を使わないで構築します。 システム構成は以下のようになります。 Slack→Lambda連携では、Content-Type について Slack「Outgoing WebHooks」出力は、 application/x-www-form-urlencoded AWS「Lambda」入力は、application/json なので、API Gateway での Content-Typeの変換処理がポイントになります。 以下、順番に作成していきます。 AWS側の設定 最初はLambda関数から。 Step 1: Select blueprint
はじめに Amazon EC2でLinuxサーバを新規構築する場合は弊社ではAmazon Linuxをお勧めすることが多いです。その理由としてはAWSのツールが最初から入っていてAmazonのサポートも受けやすいからです。Amazon Linuxを使ったことがない方はどんなディストリビューションなのか特徴を知りたいのではないかと思いますので、CentOSとの違いも含めまとめてみました。以下はAWS公式サイトのページになります。 Amazon Linux AMI Amazon Linuxの特徴 Amazon LinuxはRedHat系のディストリビューションになります。CentOSやRHELを使ったことがある方なら同じように使えるのではないかと思います。CentOSとの比較をしながらAmazon Linuxの特徴を見ていきたいと思います。CentOSはAWS MarketPlaceにあるCe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く