Alternative Architecture DOJO Offline #3での資料です。

ECS を利用したアプリケーションを構築する上でデプロイ戦略の選択は重要な要素になります. 開発段階では ECS が制御するローリングアップデートを利用して手動デプロイすることはあっても, 本番環境では自動デプロイが好ましいでしょう. 今回はCodePipelineを主軸に自動デプロイできる環境を構築します. デプロイ戦略の概要について 今回はパイプライン内でDocker Imageをビルド, pushを行った後に, ECS ServiceをBlue/Greenデプロイします. またDocker Imageに付与するタグとしてgitのコミットハッシュを利用することでコードとイメージを一意に紐づけることも同様に行います. パイプラインの構築は主にTerraformを利用しますが, 一部AWS CLIを利用します. 今回は検証が目的のため, 本番環境を意識したコード分割などは行っていません.

セッションマネージャーを導入しようと思ったそこの貴方！まずは既存の環境や導入予定の新規環境を見直してみませんか？プライベートサブネットにあるEC2への通信方法を考えながら、それぞれの長所・短所をまとめてみました。どのような通信方法を選ぶかを考える際の参考にして頂ければ幸いです。 ブドウ糖てんこ盛りな ラムネ菓子は良いぞ。 長時間の資格試験、集中力が大事な作業、一気に書き上げたいブログ…… ラムネは全てにおいて有用です。 ▲ 目が"冴えます" 突然の熱いラムネ推しからこんにちは。今まさにラムネをかじっているAWS事業本部のShirotaです。 ずっと甘味と言えばチョコレート最推しだったのですが、脳に直接甘味が効くと感じられてからはラムネを食べる頻度が増しています。 ただラムネに含まれるブドウ糖の有用性を語ろうと思って検索しようとしたところ、「ラムネ 太る 」という心を貫くサジェストに出くわし

とうとうきてしまいました！ とうとう、ALB一つだけでターゲットグループの重み付けが出来るようになってしまいました！！！！ ALBでターゲットグループの重み付けができるようになり、Route53で設定しなくても良くなりました。 AWSエンジニアは朝5時に起きるらしいと聞いていましたが、まさか自分がそっち側に回るとは思ってもいなかったもこ@札幌オフィスです。 とうとうきてしまいました！ とうとう、ALB一つだけでターゲットグループの重み付けが出来るようになってしまいました！！！！ Application Load Balancer simplifies deployments with support for weighted target groups New – Application Load Balancer Simplifies Deployment with Weighted T

AWS SESは安価で簡単にメールの送信／受信トリガーが実現できるサービスです。AWSを使っているサービスの場合、けっこう使うことになると思います。が、ハマりどころや注意すべき所があるため、サービスの特性を理解して使ったほうが良いと思い、まとめてみました。 やること SESの制限解除申請をする DKIMに対応する／逆にSPFは対応しなくてOK バウンスと苦情の対応をSNS/SQSなどを使い自動化する 25番ポートは使用せず、465/587を使用する 配信メトリクスを監視する SESの制限解除申請 新規AWSアカウントの場合、SESはサンドボックスモードになる サンドボックスモードだと、検証済みEmail/ドメイン宛にしか送信できない 24時間あたり200通までの送信制限 / 1秒あたり1メッセージの受信制限 サンドボックスモードを解除するには申請する 制限はリージョン毎に行われる 詳しくは

ECSのスケーリング戦略を柔軟に設定でき、さらにFargate Spotを活用できるCapacity Provider、皆さんすでにお使いでしょうか？ re:Invent2019の開催中に突如発表された新機能なのですが、「Fargate Spotとかいうのが使えるらしいで！」というキャッチーな側面はありつつも、その概念はECS全体を包括するもので、正直自分も最初とっかかりが難しかったです。 この記事は、CM re:Growth 2019 TOKYOで発表した内容を元に、Capacity Providerの全体像を掴んでもらうことを目的に書きました。ECSにおけるかなり大きな機能拡張なので、普段からECSを使われている方は、是非この記事でこの新機能を掴んでもらえればと思います。 （祭） ∧ ∧ Y　 ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉     Capacity Provider ﾏﾂﾘﾀﾞﾜ

構成説明 具体的なイメージとして2Tier(ALBとEC2を分離)構成を例として書いてみます。 この構成は採用されやすい構成でHTTP/HTTPS通信をALB経由でPrivateSubnetに配置されているEC2にリクエストが転送されます。 EC2はPrivateSubnetに配置されている点からインターネット経由でアクセスが出来ません。 上記のEC2構成をECSに置き換えてみます。 EC2がECSに置き換えられて、PublicSubnetにNATGatewayが追加配置しております。 これはコンテナスケーリングやコンテナイメージを取得するため、インターネットを経由して各サービス(ECS/ECR)へ接続する必要があるため必要になったNATGatewayです。 この構成で厳しいと考えられる点はNATGatewayがAZ障害等で利用不可となった際にECS/ECRへの通信が出来なくなる懸念があり

便利になった AWS Systems Manager Distributor を使ってソフトウェアを最新に保とう！！ こんにちは 園部です。 サーバー内にインストールしたソフトウェアのバージョン管理は、時としてトラブル・運用負荷となることがあります。 「ちょっと、この役割のサーバには、●●ソフトウェアはインストールするルールじゃないですか？」 「このサーバに、入っている▲▲ソフトウェアは推奨バージョンじゃない！」 「あれ？ 全部、■■ソフトウェアをインストールしているのに、一部のサーバだけ新しい機能使えない」 「新しいバージョンがリリースされたけど、またアップデート作業を計画して実施するのか....」 そんな声にこたえてくれるのが、 AWS Systems Manager Distributor です。 ちょうど昨年の今頃にリリースされましたが、使いこなすには少し手間がかかる面がありました

こんにちは、大阪オフィスのかずえです。10/11に、弊社は Developers.IO 2019 in Osakaを開催いたしました。お越し下さった皆様、ありがとうございました！ 私は今回、「AuroraかRDSどちらを選ぶべきか」というタイトルで登壇させていただきました。このエントリはその内容をブログ用にアレンジしたものになります。 ゴール AuroraとRDSの違いを理解して、 適切に使い分けることができるようになる もくじ RDSとは Auroraとは� RDSとAuroraの違い� アーキテクチャの違い� Auroraにしかない機能� RDSかAuroraどちらを選ぶべきか� Auroraを使えないケース� (Auroraも使えるけど)RDSを使うべきケース� まとめ� 登壇資料� 参考資料� RDSとは 皆さんご存知かと思いますが、RDSはAmazon Relational Da

確認したいこと ALB（Application Load Balancer）のリスナーとして設定するTarget Groupは、随時変更することができます。変更したそのタイミングでアクセスがあった場合に、エラーになることはないのか、気になったので確認しました。 図で説明 この状態から この状態に変える瞬間に このようにエラーになってしまうリクエストが発生しないか 結論 大丈夫そうです。Target Group付け替え時にエラーになるリクエストは発生しないようです。 検証方法 httpingというpingのhttp版のコマンドを使って、ローカルからALBに対して断続的にリクエストし続けます。その途中でTarget Groupの付け替えを行なって、エラーになるリクエストが無いか調べました。 Target Groupには前述の図のように、それぞれ異なるEC2インスタンスが一台ずつ紐づいています。

CloudFormationの全てを味わいつくせ！「AWSの全てをコードで管理する方法〜その理想と現実〜」 #cmdevio AWSにおける代表的なIaCの手段、CloudFormationについて、その使いこなしについて主観強めに喋ってきました。あまりマニュアルにも乗ってないような事項も結構あるので、是非参考にしてください。 「俺は、なんだかんだCloudFormationが大好きだ！」 うららかな小春日和の11月、下記イベントで登壇してきました。 【11/1（金）東京】国内最大規模の技術フェス！Developers.IO 2019 東京開催！AWS、機械学習、サーバーレス、SaaSからマネジメントまで60を越えるセッション数！ ｜ Developers.IO このブログでは、「AWSの全てをコードで管理する方法〜その理想と現実〜」というタイトルで思う存分喋ったその様子を丸ごと喋り含めて

【コンテナのデプロイを簡単にしませんか？】ECSのデプロイツールである「ecspresso」を触ってみた こんにちわ、札幌のヨシエです。 先日のAWS DevDay Tokyo 2019は自分も参加出来て本当に勉強になりました。 今回は発表された複数セッションで度々登場した「ecspresso」が気になったので使用感を知りたく触ってみました。 ecspressoとは？ 面白法人カヤック様から提供されているGo製のECSデプロイツールです。 kayac/ecspresso 読み方は「エスプレッソ」というようです。 インストール方法(macOSのみ) brew install kayac/tap/ecspresso 確認バージョン % ecspresso version ecspresso v0.11.1 ECSサービスのコードエクスポート 最初にやることとしてecspressoで管理出来る設

AWSチームのすずきです。 2019年11月7日、AWSのEC2やFargateのオンデマンド料金が 最大72%割引で利用できる新しい料金モデル 「Savings Plans」 がリリースされました。 その概要と、従来のリザーブドインスタンス(RI)との比較について紹介させていただきます。 New – Savings Plans for AWS Compute Services 概要 1年、または3年間の期間で、1時間あたりの利用費をコミットする事により、 コミット分を割引価格で利用する事が可能になりました。 AWSコンソール EC2ダッシュボードに、「Savings Plans」のメニューが追加されています。 コミットメント 1時間あたりの利用費を登録します。 購入コミットメントの最小単位は「$0.001」。 最小コミットのSavings Plans を「期間3年」「全額前払い」で購入し

こんにちは、生産性向上チームの五十嵐(@ganta0087)です。 今回はAWSアカウントの管理についてのお話です。 AWSアカウントをみなさんの組織ではどのように管理されているでしょうか？ シングルアカウントで運用していると、人やチームが増えて規模が大きくなってきたときに権限管理が中央集権的になり、管理者への負担が増大してしまいます。また、新規ユーザーの登録だけでなく、退職時の削除漏れにも注意が必要です。利用者側としても管理するパスワードが増えるのは避けたいです。 そこで、生産性向上チームではマルチアカウント構成によるシングルサインオン(以下SSO)とチームに委譲できる権限管理のしくみを作ることでこれらの問題を解決し、社内でAWSを活用しやすくなるようにしました。 サイボウズには社員のアカウント情報を管理しているActive Directory(Azure AD)があります。今回はそのA

弊社クラスメソッド株式会社主催のイベント「Developers.IO 2019 TOKYO」での登壇資料です。 セキュリティ対策メガ盛りマックス ブログ: https://dev.classmethod.jp/cloud/aws/developers-io-2019-tokyo-all-securi…

本記事はDevDay Day1のセッションレポートとなります。 資料についてもすでに公開済みですので合わせてそちらもご確認ください。 セッション概要 AWSのオフィシャルツールを筆頭に、各種OSSを使用したFargateへのコンテナデプロイを考察する。 登壇者 原 康紘 様（アマゾン ウェブ サービス ジャパン株式会社） セッションの対象と目的 Fargateの利用を検討している方 デプロイツールの特徴を知りたい方 デプロイメントやパイプラインの構築、改善を行いたい方 AWS Fargateとは Dockerコンテナをデプロイする際にツールがないとEC2インスタンスに対してSSH接続してDockerの構築が必要になる この問題を解決するためにECSがサービスとして登場した EC2インスタンス群にDockerコンテナを自動的に構築してくれる EC2インスタンス上で動いているので、OSが動いて

はじめに SREチームの @minamijoyo です。 先日 CrowdWorks (crowdworks.jp) の本番環境のRailsアプリケーションを Docker (AWS ECS: Elastic Container Service) に移行しました。 CrowdWorksは2012年にサービスを開始し、2019年10月現在、ユーザ数は300万人、月間で数億円規模のお仕事がやりとりされる、国内最大級のクラウドソーシングプラットフォームにまで成長しました。 サービスの規模拡大に合わせて、ソースコードも数十万行規模に成長し、 決して小さくはない規模のRailsアプリケーションに成長しました。 CrowdWorksの開発環境にDockerが導入されたのはもうかれこれ3年半前の2016年の4月頃、2017年1月頃にはCrowdWorks本体から切り出された一部の機能で本番環境に投入され

こんにちは。こむろです。 今年の札幌の夏はハードモードだ（湿気と暑さ） この先生きのこるためにエアコンが投入されました。 はじめに クラウドネイティブなアプリケーションを設計・構築・運用している皆さんは、普段どのようにアプリケーションやインフラの更新作業を行っているでしょうか。 順次インスタンスやコンテナを切り替えていくRolling Update？それとも環境を複製してDNS Routingの切り替えによるBlue-Green Deploymentでしょうか。他にも様々な方法があるかと思いますが、今回もまたBlue-Green Deploymentにおける実際の現場で発生した事象について報告したいと思います。 あまりネット上にもこういった情報が出てこないようなのですが、皆さんこういった問題は軽々とクリアされているのでしょうか。自分がポンコツなだけなのかととても不安にかられるばかりです。