AmazonECS / Fargate 本番運用のための構築とデプロイ方法まとめ
Amazon ECS（以下ECS）とFargateを用いて、今までEC2で運用されていたサービスをコンテナ化してECS上で稼働させるプロジェクトをしました。 特に、Fargateは2018年7月3日にTokyoリージョンで使えるようになったばかりなので、情報がまだまだ少なく手探りの状況でした。 Posted On: Jul 3, 2018 AWS Fargate is now available in Asia Pacific (Tokyo) region. https://aws.amazon.com/about-aws/whats-new/2018/07/aws-fargate-now-available-in-tokyo-region/ ECS/Fargateで実現したアーキテクチャ・デプロイ方法の全容とその実装方法を記していきます。以下のスライドにもまとめているのでぜひご覧ください
Big Sky :: 書評「Go言語による並行処理」
O'Reilly Japan, Inc. 様に献本頂きました。ありがとうございます。 そして献本頂く際にお声を掛けて頂いた、本書の翻訳を担当された ymotongpoo さんにもお礼を申し上げます。ありがとうございます。 本書の訳は非常に素晴らしく、とても原文が英文であったとは思えないほど綺麗で、読んでいく中で「原文でどの様に表現されているんだろう」といった引っかかりも無く、とてもスムーズに読み進められました。 Go 言語に関わって随分と長くなってきました。初めて Go を知ってからユーザがどんどん増える様を見る事が出来るのは正直に言って非常に嬉しいです。 ふと Go の魅力は何かと聞かれたら幾つか挙げる事が出来ますが、間違いなく選ぶのが「非同期処理の簡単さ」です。これまで多くの開発者が OS スレッドで実現してきた非同期処理を、Go 言語は少ないイディオムとインテリジェントなランタイムを
シンプルさとパフォーマンスを両立した API 設計と実装の一例 - HeartRails Tech Blog
こんにちは、エンジニアの村田です。今回はシンプルさとパフォーマンスを両立した API を作るためにはどうすればよいのかについて述べていきます。 背景 いままで API サーバーを作ってきて、シンプルな API にすればパフォーマンスが犠牲に、パフォーマンスを優先すれば実装が複雑になって保守が大変になるということを経験してきました。具体的には、 関連リソースの Entity が何重にもネストしていたり、同じリソースに一覧用、詳細用などの Entity があり実装、保守が大変 1. の問題を解消するためにシンプルな API にする 2. では N+1 の問題がありパフォーマンスが悪い 1. 2. の問題を解消するためにリソースの Entity はシンプルにしつつ、パラメーターで関連リソースを指定すると関連リソースの Entity を埋め込んで返すようにする 4. だと関連リソースの権限管理やペ
疲弊しないためのCloudFormation管理手法 - Engineering blog at ktrysmt
May 5, 2018 私も日々お世話になっている大変便利なCFnですが、上手に付き合うにはいくつかコツがいるのかなぁと感じたので、要点と管理手法をまとめました。 つらいところ NestedStackがつらい まずStackを事前にS3へ上げないといけないというのが…。 S3Bucketももれなくワンオフで管理したい身としては、stack間の前後関係はなるべく排除したいのです。 また、個人的な信条として、stack間の依存を許容するのはIAMリソース程度に留めたいです。 そんなわけでaws cloudformation packangeも、CFnの管理という点においては嬉しくなく…。 S3を介するのでなくstackテンプレート間の相対パスの解決を、手元でやってほしかったです。 Outputの取り扱いが難しい NestedStackを諦めるとすると、テンプレートを分割する場合、相互参照はおお
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Chrome」からWindows/Mac/Linuxへリモート接続！ Googleが公式提供する無償ツール【レビュー】 - 窓の杜
