Amazon Web Services ブログ AWS Lambdaによる進化的アーキテクチャの構築 この投稿は、メディアとエンターテインメントのプリンシパルソリューションアーキテクトであるLuca Mezzaliraによって書かれました。 俊敏性により、必要に応じてワークロードを迅速に進化させ、新機能を追加したり、新しいインフラストラクチャを導入したりできます。コードベースでアジリティを実現するための主な特徴は、疎結合コンポーネントと強力なカプセル化です。 疎結合は、テストカバレッジを改善し、一貫したリファクタリングを作成するのに役立ちます。カプセル化を使用すると、実装ロジックを明らかにすることなく、サービスとのやり取りに必要なものだけを公開できます。 進化的なアーキテクチャは、設計の俊敏性を実現するのに役立ちます。「進化的アーキテクチャの構築」という本の中で、このアーキテクチャは「複数
Docker Compose と Amazon ECS を利用したソフトウェアデリバリの自動化 | Amazon Web Services
Amazon Web Services ブログ Docker Compose と Amazon ECS を利用したソフトウェアデリバリの自動化 この記事は Automated software delivery using Docker Compose and Amazon ECS を翻訳したものです。 2020 年 11 月、Docker Compose for Amazon ECS の一般提供を開始しました。開発者はコンテナ化されたマイクロサービスベースのアプリケーションをワークステーションから取り出し、AWS クラウドに直接デプロイすることがさらに簡単になりました。以前紹介したこのブログにあるように、開発者は docker compose up コマンドを実行して既存の Docker Compose ファイルをそのまま Amazon ECS にデプロイできます。Docker Comp
はじめに 4年ぶりの開催となるServerlessDays Tokyoに参加してきました https://tokyo.serverlessdays.io/ 「もっとうまくやりたい、誰よりも上手にやりたい」 というメッセージとともに開催されたServerlessDays Tokyo 2023ですが、超豪華なスピーカー陣を国内外から集め、ここ数年のServerlessの成熟と未来をしっかりと味わえる濃いイベントです。 1日目がセッション、2日目がワークショップということで、熱力の高いうちに激熱なサービスを素早く学べる構成になっていて、とても充実した内容でした。 所感 4年前のServerless LambdaをはじめとするFaaSをいかに簡単にデプロイ、運用していくかというツール系の話と S3やSQS,SNSなどのFaaS以外のServerlessなサービスの組み合わせでLowOpsな仕組みを
[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO
水平分散のアーキテクチャを考えるときに、「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」「AWS であれば３ AZ にまたがるとよい」とはよく聞かれます。それがどういう意味をもつのか、主に可用性の面から考えてみました。 みなさん、AWS使ってますか！（挨拶 AWSに限らず、ある程度の規模の何かしらの本番システムを組もうというときに、こういう言葉を聞いたことはないでしょうか。 「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」 「AWS であれば３アベイラビリティゾーン (AZ) にまたがるとよい」 負荷分散装置（ロードバランサー）は負荷を分散するのがお仕事です。分散するだけなら 2 台でもよさそうですよね？ AWS の３ AZ に至っては、そもそも AZ 単位の障害なんてそうそうないし、あったとしてももう片方の AZ が生きていればなんとかなりそうに思えます。
![[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/876809e40a16193d45c580a01a3f67fc9a50a044/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Felastic-load-balancing.png)
「AWSコンテナ設計・構築 [本格] 入門」を執筆しました - horsewin's race records
はじめに AWS x コンテナに関する商業誌を執筆しましたので、本ブログにて少し内容を紹介できればと思います。 （しかし、見本誌をつみあげるとなかなか圧巻でした！） amzn.to 見本誌 こちら、共同執筆者の新井さん (@msy78)や、監修いただいた佐々木さん(@dkfj)のブログでも触れられている内容になります。執筆に至った経緯などはお二人のブログでも語られていますので、↓をどうぞ。 『AWSコンテナ設計・構築[本格]入門』の監修しました - プログラマでありたい 「AWSコンテナ設計・構築 [本格] 入門」を執筆しました - How elegant the tech world is...! このブログでは執筆者の一人である、私の視点からの書籍の紹介をいたします。 書籍について 本の概要 全5章で構成しています。本当は付録としてECSコンテナを扱うためのツールもいくつか紹介するため
![「AWSコンテナ設計・構築 [本格] 入門」を執筆しました - horsewin's race records](https://cdn-ak-scissors.b.st-hatena.com/image/square/57141c70a523f08768a755a651bc869b2e57dd7e/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhorsewin%2F20211010%2F20211010235628.png)
最近何をやっていたかというと、タイトルの通り、Pathtraqというサービス、iPhoneアプリを作っていた。どんなサービスかと聞かれるとLifeLogというのが一番適切だと思うけど、LifeLogにも種類があって、これは位置情報を記録して検索するサービスになる。 https://pathtraq.tagomor.is/ PathtraqApp Satoshi TagomoriProductivityFreeapps.apple.com どういうためのものかというと、普段生活したりどこかに行ったりして、以下のようなことが気になる方向けです。 この場所/店/街、最後に来たのいつだっけ? 前に飲みにいってふらっと入ったあの店、どこにあった何ていう店だっけ? 前にあそこからあっちに移動したとき、どのくらい時間かかったっけ? なんかさあ、この程度のこと、全部記録とってあれば簡単にわかるはずなんだけ
CTOになったToriです。せっかくの機会なのでエンジニアとしてのキャリアを振り返ってみました - Findy Engineer Lab
前職のAmazon Web Services（以下、AWS）でコンテナスペシャリストソリューションアーキテクトやデベロッパーアドボケイトを務め、2022年4月より株式会社カミナシに転職したHara Tori(@toricls)さん。 2022年7月1日に、彼がCTOに就任したことが発表されました。 Findy Engineer Lab編集部は、就任間もないToriさんにインタビュー。著名エンジニアである彼が、どのような経験を積んでスキルを研鑽してきたのか、そしてカミナシで何を目指すのかを伺いました。彼の歩みから見えた「エンジニアがより良いキャリアを実現するための方法」とは。 「あなたは大手企業には向かないと思う」 ――改めまして、CTO就任おめでとうございます。せっかくの機会ですので、Toriさんのキャリアを総括したインタビューをさせてください。コンピューターに興味を持ったのは、いつ頃から
SREチームの長田です。 今回はカヤックで運用している「まちのコイン」というプロダクトのアプリケーション基盤を Amazon EKS(以下EKS)からAmazon ECS(以下ECS)に移行したはなしをします。 まちのコインとは coin.machino.co www.kayac.com まちのコインはカヤックが運営している、デジタル地域通貨を使ってその地域のコミュニティを活性化させるサービスです。 2019年11月から実証実験を開始し、翌年2月から正式リリースされました。 2022年9月現在、20の地域に導入されています。 一般ユーザーが使用するクライアントアプリと、導入地域の運営団体が使用するブラウザ用の管理画面、 それらにAPIを提供するRailsサーバーアプリがあります。 データベースはAmazon Aurora PostgreSQL、 その他AWSのマネージドサービスを組み合わせ
AWS、コンテナ特化で瞬時に起動する軽量VM「Firecracker」オープンソースとしてバージョン1.0に到達。AWS LambdaやAWS Fargateで利用
Amazon Web Services（AWS）がオープンソースとして開発し、コンテナの実行に特化した軽量な仮想マシン「Firecracker」がバージョン1.0に到達しました。 Firecrackerは2018年11月に行われたAWSのイベント「AWS re:Invent 2018」でオープンソース化が発表されました。コンテナのために作られた仮想化技術で、同社が「マイクロVM」と呼ぶセキュリティにフォーカスして設計されたスリムな仮想マシンです。 AWS Lambdaのような高速なサーバレス環境を実現するために同社が開発しており、実際にAWS LambdaやAWS Fargateで利用されていると説明されています。 基本的な特徴として、小さなメモリフットプリントとオーバーヘッドに加えて、外部から攻撃可能な部分を最小限にするなどのセキュリティ対策を実装しています。 速度にもフォーカスしており
初めてFargateを触ったので、運用保守の観点で構築時に設定しておいた方が良いポイントをまとめました。 デプロイの自動化と書いているのにデプロイの話薄めになってしまいました…。 こちらはJAWS-UG朝会 #28で発表したものになります。
AWS DevDay Japan 2022 に「AWS CDKでECS on FargateのCI/CDを実現する際の理想と現実 」というタイトルで登壇しました #AWSDevDay | DevelopersIO
はじめに CX事業本部の佐藤智樹です。 先日AWS DevDay Japan 2022 というイベントで「AWS CDKでECS on FargateのCI/CDを実現する際の理想と現実」というタイトルで登壇しました。 今回は上記の登壇で使用した資料の公開と発表の補足を記載いたします。 登壇動画 登壇資料 発表理由 1年前に上記の構成を始めた際に、思っていたよりは理想の状態にできないことが多々あり、情報も多くないように感じたので少しでも参考になるように実践例をベースにまとめました。同じような構成を試される際は参考になるかと思います。また発表の1ヶ月以内(2022/09~10)に結構更新があったので、昔同じ構成試してダメだった部分があったかたも参考になる部分あるかと思うのでみてもらえると嬉しいです。 最後に 本当は資料90ページぐらいになってタイトルと関連性の薄い内容（ECS on Farg
potato4dとうなすけが2020年に使用した技術をそれぞれフロントエンドエンジニアの目線とサーバーサイドエンジニアの目線から書いてくれていたので、私も感化されて記述していこうと思う。d.potato4d.me blog.unasuke.com 私自身は2020年、本業としてFringe81（2020年12月で退職）でサーバーサイドをメインで触り、業務委託としてBlack Inc.でフロントエンドに近い開発をしていた。（あと数社お手伝い） どちらかというとサーバーとフロント、両方の立場から多角的な意見を言えるような立ち位置で仕事を行っていた年になる。 また本業においては情報処理安全確保支援士として活動を始めた年になった。社内のセキュリティ向上を目標としていた。 qiita.com qiita.com 今回は仕事で触れていた技術について、できる限りまとめていく。 --- 言語 TypeSc
AWS×コンテナで基本的なDevSecOpsアーキテクチャをデザインしたお話 - How elegant the tech world is...!
はじめに 先日、僕が担当する業務でECS/Fargate利用を前提にDevSecOpsアーキテクチャをデザインし、社内のAWS勉強会にて登壇する機会をいただきました。 本ブログでも内容をかいつまんでご紹介できればと思います。 AWSによらず、コンテナを利用されている方にとって、一つのプラクティス例としてご参考になれば幸いです。 ※コンテナ自体の説明や必要性に関する内容は省略していますm(_ _)m そもそもDevOpsとは？ DevSecOpsの導入意義をお伝えするた前に、まず軽くDevOpsの意義をお伝えします。 ※とは言え、この記事をご訪問されている方にとっては「何をいまさら...」な内容かもしれませんし、ググればDevOps自体の情報はたくさん見つかりますので、重要なポイントのみ述べることにします。 DevOpsとは、一言で述べれば、開発チームと運用チームが協力してビジネス価値を高め
Amazon Web Services ブログ AWS Batch ベストプラクティスまとめ この記事はプリンシパル HPC ソリューションアーキテクトの Pierre-Yves Aquilanti、AWS Batch のプリンシパルプロダクトマネージャの Steve Kendrex とプリンシパル HPC アプリケーションエンジニアの Matt Koop によるものです。 更新: 2021 年 10 月 5 日 セクション 2 に於けるサブネット CIDR ブロックのガイドラインを修正。 AWS Batch は、科学者や技術者が複雑なシステム構成を管理する必要なく、自由にスケールできる計算環境を提供するサービスです。2017 年に登場して以来、疫学、ゲームシミュレーション、大規模機械学習といった諸々のワークロードを稼動させる様々な業種や組織といったお客様に採用されてきました。 この投稿で
DockerとAWSのコラボによりdocker ecsコマンドが爆誕したので使ってみた | DevelopersIO
Docker社とAWSがコラボレーションするという驚きとともに、新しくdockerコマンドに組み込まれたdocker ecsの使い心地を試してみました。 「docker ecsコマンド？なにこれ？」 先日、突如、DockerのECSインテグレーションなるものが発表されました！ AWS and Docker collaborate to simplify the developer experience | Containers 従来あるdockerコマンドに、なんとdocker ecsコマンドが追加され、docker-composeファイルを利用したECSへのデプロイがAWS CLIなどのAWS製ツールを使わずに、全てdockerコマンドだけで完結するという、ちょっと想像がつかないアップデートです。 まだDocker社ではベータ版の扱いということですが、なかなかにおもしろいアプローチだった
0.THE FRUGAL ARCHITECT (倹約的なアーキテクト) 2023年11月下旬に開催された re:Invent 2023 のキーノートにおいて、Amazon CTO のワーナー・ヴォゲルス氏が「THE FRUGAL ARCHITECT (倹約的なアーキテクト)」という考え方をお話されました。 とても刺さる内容となっており、今後私なりの解釈を整理して記事化してみたいと考えています。 1. はじめに 近年、様々な企業や組織でAWSの利用が広まってきましたが、AWS活用をしていく中で適切なコスト管理は欠かせません。 適切なコスト管理ができていないと、予想外の箇所でコストが発生し、それに気づかないまま無駄な費用が 長期間にわたって発生し続ける恐れ があります。そのため現時点でどのくらいの費用がかかっているのかを正確に把握し、それを分析して最適化する必要があります。 2.主要なポイント
技術書典#13向けに「Amazon CloudWatch [本格]入門」を執筆しました - How elegant the tech world is...!
はじめに お久しぶりです。最近は疎かになっていましたが、久々のブログ投稿となります。 今回はタイトルの通り、技術書典#13向けに「Amazon CloudWatch [本格]入門」を執筆しました。 本ブログにて少しご紹介できればと思います🚀 techbookfest.org 今回も表紙がかなりかわゆい感じになっていますが、内容はガチガチの技術書です。 書籍の位置付け 技術書典はかれこれ2019年にオンライン開催された技術書典8が初参加です。 その時はコンテナ(Amazon ECS / AWS Fargate)+CI/CDを主テーマにした「クラウドネイティブファーストストーリー」を執筆しました。 2年後の技術書典11にて、同じくクラウドネイティブシリーズ第2弾として「比べてわかる！IaCの選びかた」を世に送り出しました。 booth.pm booth.pm 今回の書籍は、そのクラウドネイテ
![技術書典#13向けに「Amazon CloudWatch [本格]入門」を執筆しました - How elegant the tech world is...!](https://cdn-ak-scissors.b.st-hatena.com/image/square/eca7b4ab7b1d47a757330bf1f21e8f2a08c25534/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fi%2Fiselegant%2F20220910%2F20220910000216.png)
概要 ソーシャル経済メディア「NewsPicks」SREチームの中川です。 皆さんはバッチ処理基盤はどうされていますでしょうか。 NewsPicks では少し前まではそれらをEC2、cronの組み合わせで動作させていました。 何年も前からこの仕組みだったのですがSREとしてはEC2の面倒見るのも手間ですし、それ以上にcronを変更する際のオペレーションミスが目立ったのが懸念点でした。 その為、まずはAWSマネージド化するための基盤を整備し、その後バッチアプリを載せ替えていくようにしました。 対応前の基盤構成 同じSREチームの安藤さんが CloudNative Days Tokyo 2023 で登壇されたときの資料をお借りします。 ご覧の通り、大体のサービスはマネージド化していましたがバッチ基盤だけは旧来のままEC2インスタンスを利用していました。 10年モノのサービスのインフラを漸進的
Docker ComposeのAmazon ECSデプロイを試してみた - SMARTCAMP Engineer Blog
スマートキャンプ、エンジニアの入山です。 2020年7月にDockerとAWSのコラボレーションにより、単一コマンドでDocker ComposeのyamlファイルからAmazon ECS上に各コンテナをデプロイできる機能追加が発表され、非常に注目を集めました！ From Docker Straight to AWS - Docker Blog AWS and Docker collaborate to simplify the developer experience | Containers ローカルでDockerを利用して開発を行っている方々は、ほぼ間違いなくDocker Composeを利用してアプリの動作に必要な各コンテナを一括管理しているかと思いますが、このECS Pluginを利用するとAmazon ECSへの各コンテナのデプロイとECSの動作に必要な各AWSリソースを一括し
EC2やFargateが最大72%割引となる新しい料金モデル「Savings Plans」がリリースされました | DevelopersIO
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年」「全額前払い」で購入し
Amazon Web Services ブログ AWS ファイルストレージサービスの選び方 オフィス文書や画像データなどの様々な非構造化ファイルを、ファイル共有サーバや NAS（Network Attached Storage） などに格納して共有で利用されている方も多いと思います。AWS のファイルストレージサービスを利用することで、ファイル共有ストレージを簡単にクラウド上へ構築できます。また、AWS が提供するフルマネージドサービスのため、パッチ適用やストレージのディスク増設などの運用負荷を軽減できるメリットがあります。初期費用が不要の従量課金のため手軽に利用でき、調達が不要なのですぐに利用を開始することができます。また、ストレージのバックアップ機能が備わっているため、手間のかかるバックアップの設計や運用負荷も軽減できます。 AWS のファイルストレージサービスは、Amazon Ela
Amazon Web Services ブログ AWS Copilot のご紹介 Amazon Elastic Container Service (Amazon ECS) をご利用中、あるいはご利用を検討されている皆さまへ 本記事でご紹介する AWS Copilot は Amazon ECS CLI の後継に当たるものです。日本はこの ECS CLI を多くのお客様にご利用いただいている地域の1つであることに加え、ECS でのコンテナ実行をもっと簡単に行えるようにしたい、シンプルなワークフローを実現したいというリクエストを多数いただいていることから、本記事を英語記事と同じタイミングで公開することにしました。 Amazon ECS でのコンテナ実行に新たな体験を提供する AWS Copilot の紹介記事です。お楽しみください！ −トリ (皆さまからの Copilot へのフィードバック、
ちょいとした用途において、カジュアルにFargateの起動／停止を繰り返して、気ままに負荷全開かけていたら、あまりの違和感にCPU割り当てについて調査することにしました。 最近こんなことばっかやってる気がしますが、気に食わんかったからムカムカ解消に書くしかないんや。半分くらいブラックボックス与太話な感じで夜露死苦です。 はじまり とある処理を全開でFargateにやらせて、cpu=1024(100%), 2048(200%), 4096(400%) でどのくらい RPS (requests per second) でるかを計測していると、想定通りならほぼ比例でRPSが伸びるはずが、全然そうならないパティーンに遭遇。 並列過剰やエラー・バグ起因ではないことをほぼ確させた上で、まさかCPUガチャじゃあるまいなと試したら、まんまCPUガチャでしたということで、EC2からある話ではありますが、現在
2021/10/22追記：最新版は下記記事になります！こちらもご一読くださいませ。 tech-blog.abeja.asia どうも、Tech Blog編集長(自称)の緒方(@conta_)です。 よくエンジニアの方にご質問いただく ABEJAってよく聞くけど、実際どんなことやってるのかよくわからない という点をクリアにするために、事業内容と技術視点でのABEJAの取り組みを紹介したいと思います。 ABEJAに興味のある方や、未来の一緒に働くメンバーに読んでいただけると嬉しいです！ 割とAIコンサルの会社と思われているらしいので、ちゃんとプロダクト作ってますよ！ということを伝えていきたい ABEJAの事業紹介 ABEJAは2012年から約7年間、機械学習・ネットワークやIoTデバイスを活用したプロダクトの研究・開発・運用を行っています。 様々な産業・業種へ機械学習の適用・運用を培ってきたナ
MongoDBであるメリットが無くなってしまったのでMySQLに移行したはなし - KAYAC engineers' blog
SREチームの長田です。 この記事はTech Kayac Advent Calendar Migration Track 1日目の記事です。 今回はLobiで使用していたMongoDBをMySQLに移行したはなしです。 MongoDBを何に使っていたか DAUなどのKPIレポートや、サービスの状況を把握するための各種集計結果を保存するために使っていました。 サービス開始直後はこれらの数字を色々と試行錯誤しながら追加したり、減らしたりしていました。 頻繁な追加削除があるデータ構造を保存するために、スキーマレスなデータベースであるMongoDBはちょうどよかったようです。 (当時スキーマレスデータベースが流行っていたというのもあるでしょう) なぜ移行したのか MongoDBに保存されたドキュメントは、スキーマ管理がされていませんでした。 スキーマレスであることをいいことに、その時時によって様々
C5が一歩抜けた強さの割に全部 ECU=10 な時点でアレですが、さらに6g系は該当なしです。で、費用的には c5/m5 の比率と c6g/m6g の比率は同じ 86% です。 第５世代では、C5 はメモリが少ない分、安くCPUが高速だったので強い選択肢でしたが、第６世代ではメモリが少ない分、安い。だけになるので、C系を選ぶメリットがだいぶ弱くなりそうです。 単純に、14％安くしてc6gにするって考えよりも、14％高くしてメモリ倍の方がよくねっていう。そういうパターンのほうが多いんじゃないかと、いうだけで全然絶対じゃないですけど。 考えようによっては、AutoscalingGroupに複数のインスタンスタイプを指定するとき、c6g, m6g, r6g と混ぜてもCPU使用率の格差がAZ以外で起きづらくなるだろうから、扱いやすくなると言えなくもない。 vs C5 あまりに差が付きすぎて、自分
はてなブログをECSに移行してリリース頻度も改善した話 - Hatena Developer Blog
この記事ははてなエンジニア Advent Calendar 2022の26日目のエントリです。 こんにちは id:cohalz です。はてなブログでは2022年7月にインフラをAmazon EC2からAWS ECS(AWS Fargate)に移行するプロジェクトが完了しました。 プロジェクトは2021年9月から始まったので約10ヶ月間という大きなプロジェクトでした。 プロジェクト完了までに行ってきたことのうち、特に面白かったところなどをこの記事で実施した順に振り返ってみます。 はてなブログのインフラのこれまで アプリケーションを動かせるようにする ALBを追加する 検証環境を用意だけしておく プロキシの設定埋め込み 証明書の配信 アクセスログを配送できるようにする アクセスログの形式を新しくする EC2でもFirehoseを経由するように タイムゾーンをUTCに統一 FirehoseのLa
4年弱勤めた AWS を2022年3月末付けで退職します. 本日が最終勤務日です. 在籍期間中には多くの AWS ユーザーや同僚にお世話になりました. 感謝の気持ちを込めて、退職報告をしたためます. 基本的にはポエムなので、忙しい方は次のまとめセクションだけで十分だと思います. TL;DR 2022年3月末をもって AWS を退職します ネガティブな理由での退職ではありません. 挑戦こそ我が人生というやつです. 次は4月から日本のスタートアップ企業にて Software Engineer として働きます 本文読むのは面倒だけど質問がある方は本記事末尾の FAQ をあわせてどうぞ AWS 入社当時の思い出 当時 AWS Japan でサーバーレス スペシャリスト ソリューション アーキテクト (SA)1 を務めていた西谷さん2に誘ってもらい、2018年の5月末に入社しました. AWS 入社後
公開日 2024/06/18更新日 2024/06/18身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 多くのIT企業では、ユーザーに対してより高品質で安定した体験を提供するために、システムアーキテクチャを進化させ続けています。 本特集では、日常生活の中で多くのユーザーに利用されているサービスのアーキテクチャ設計に携わるエンジニアの方々から、技術選定の背景や意図、そして現在のアーキテクチャの課題から未来への展望まで、詳しく伺いました。この記事を通じて、各企業のエンジニアたちがどのように技術的な課題を克服し、システムの柔軟性と効率を高めているのか、知見を得ていただければ幸いです。 ※ご紹介は企業名のアルファベット順となっております アソビュー株式会社 アソビュー株式会社では「遊び」という領域に対し、マーケットプレイス型EC「アソビュー！」やD2C型SaaS
"壊れにくい"データ基盤を構築するためにMackerelチームで実践していること - Hatena Developer Blog
こんにちは。MackerelチームにおいてCRE（Customer Reliability Engineer）をしているid:syou6162です。主にカスタマーサクセスを支えるデータ基盤の構築や、データ分析を担当しています。 今回は、壊れにくいデータ基盤を構築するため、Mackerelチームで実践していることを紹介します。 なぜ壊れにくいデータ基盤を構築するのか データ基盤が“壊れている”とはどういうことか 壊れてないだけでなく、壊れたら気付ける 前提とするシステム構成 壊れたことに気付けるよう監視する 1. バッチジョブが失敗したことに気付く 2. 投入されたデータの性質を監視する 3. ビューが壊れてないかを監視する 4. 利用状況を監視する そもそも壊れてない状態を保つ 1. データリネージを元に修正できるようにする 2. 使われていないテーブルやビューは定期的に掃除 おわりに 参
[激アツアップデート]ALBだけでカナリアリリース(重み付け)ができるようになりました！ | DevelopersIO
AWSエンジニアは朝5時に起きるらしいと聞いていましたが、まさか自分がそっち側に回るとは思ってもいなかったもこ@札幌オフィスです。 とうとうきてしまいました！ とうとう、ALB一つだけでターゲットグループの重み付けが出来るようになってしまいました！！！！ Application Load Balancer simplifies deployments with support for weighted target groups New – Application Load Balancer Simplifies Deployment with Weighted Target Groups 従来までのBlue/Green(カナリアリリース) デプロイ方法 重み付けをしてトラフィックの数パーセントを新しい環境に流すような場合は、複数のロードバランサーを用意した環境で、Route53にて重み付
[AWS][Fargate]ECS Scheduled TasksによるNAT Gatewayの通信費肥大化について
[AWS][Fargate]ECS Scheduled TasksによるNAT Gatewayの通信費肥大化について投稿者: adachin 投稿日: 2021/04/082021/04/08 まずはNAT Gatewayの膨大な通信費を見てほしい….(驚愕) ECS/FargateでECS Scheduled Tasksを運用していると、NAT Gatewayの通信費が膨大にかかってしまうことがあると思います。今回はこちらをどのようにコストを削減したのかブログしたいと思いますので、ぜひ参考にしてみてください。まずは経緯から！ 経緯 改善する前の構成図を書いてみました。ECS/Fargateで動作しているAppコンテナ(Private subnet)ですが、デプロイ時やECS Scheduled TasksでのバッチはNAT Gatewayを経由してECRからDocker imageをpu
AWS FargateではなくECS on EC2を選ぶメリット〜コスト編〜 - Uzabase for Engineers
このブログは NewsPicks Advent Calendar 2022 1日目の記事です。 qiita.com NewsPicksのSREチームでリーダーをしている安藤です。 NewsPicksに入社して1年が経ちましたが、最近は円安により親の顔よりもAWS Cost Explorerを見る毎日です。 ということで、コストの話をしていきたいと思います。 NewsPicksでのコンテナ移行について ECS on EC2とは？ コンテナの実行環境としてFargate or EC2を選択する時の評価基準 実際、Fargateはどれだけ割高なの？ CPU性能の比較 コンピューティング料金の比較 パフォーマンスに対するコスト コストに対して、マネージドサービスのメリットが上回るか 終わりに NewsPicksでのコンテナ移行について NewsPicksでは、Amazon ECSによる全面コンテナ
こんにちは。 メディアサービス開発部バックエンド開発グループのフサギコ(髙﨑)です。 Ruby on Railsによるバックエンドの実装運用と、AWSによるサービスインフラの設計構築を中心とした、いわゆるテックリードのような立ち位置で働いています。 本記事では前記事のニコニコ漫画のインフラ構成についてに続いて、読書メーターのサービスインフラの概要について軽くご紹介したいと思います。 読書メーターについて 読書メーターは、2008年5月に開設された日本最大級の読書コミュニティサイトです。 単純な読書記録や感想投稿に留まらず、ユーザ間で交流ができること、出版各社さまからご提供いただき著者さまのサイン本や発売前に校閲校正をする際の仮刷りであるプルーフと呼ばれる段階の本が貰える献本プレゼント企画を行っていることも特徴的な点です。 読書メーターの構成 読書メーターは下記の6つのコンポーネントから構成
AWS ECS on Fargate + FireLens で大きなログが扱いやすくなった話 | BLOG - DeNA Engineering
はじめに コンテナオーケストレーションサービスの一つである AWS ECS on Fargate (以下 ECS on Fargate) では、FireLens を利用することで、コンテナが出力するログを簡単に任意のログ基盤へ送信できます。 しかし、FireLens を通じてコンテナのログをルーティングする場合、16 KB 以上のログは分割された状態でログルーティング用のコンテナに到達します。構造化ログを実現するためにアプリケーションが JSON などの形式でログを出力している場合、ログを分割される前の状態に復元する必要があります。 この記事では、FireLens とは何かをおさらいした上で、上記の問題の背景を解説します。また、この問題の解決策についてこれまで知られてきた方法と、最近の ECS on Fargate のアップデートにより利用できるようになった方法を解説します。それにより、読
Vimを支える技術: Alacritty, AquaSKK, tmux, Language Server… 高速ウェブ開発の世界
はじめに これは、ストックマーク Advent Calendar 2021 17日目の記事です。こんにちは、ストックマークでAstrategyというビジネス向けSaaSについて、主にフロントエンドの開発を担当している@tsukkeeです。 Astrategyの技術構成については以前にAstrategyを支える技術: gRPC, Elasticsearch, Cloud TPU, Fargate... SaaS型AIサービスの内側の世界という弊社テックブログ記事で紹介したことがあるのですが、本記事ではその開発環境の一部を紹介したいと思います。 さて、開発環境と言えばテキストエディタですが、皆さん開発にはどのテキストエディタ(またはIDE)を使っていますでしょうか？本記事のタイトルにもあるとおり私はVimを使っています。ただ、Astrategyの開発チームでは使うテキストエディタに制限はなく、
踏み台の管理コストを削減！ECS ExecとTerraformでつくる本番オペレーション環境 - LIVESENSE ENGINEER BLOG
こんにちは。マッハバイトを運営するアルバイト事業部エンジニアの mnmandahalf です。 みなさんは本番DBへのSQLの手動実行等の作業をどんな環境で行なっていますか？ 通常はDBにアクセスする用の踏み台サーバにSSHログインして作業を行うケースが多いと思います。 マッハバイトでも最近まで（現在もDBによっては）踏み台を使用していたのですが、最近新・本番作業環境を導入したのでその背景とつまづきポイント等についてご紹介します。 これまでのマッハバイトにおける本番作業 これからのマッハバイトにおける本番作業 TerraformでのECS Execの設定方法 ECSタスクロールにアタッチするポリシードキュメント ECS Execを実行するのに必要なIAMにアタッチするポリシードキュメント ECSクラスタでexecute-commandの監査ログをCloudWatchに流し、ログをKMSキー
達人出版会
探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う！ オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 R／RStudioでやさしく学ぶプログラミングとデータ分析 掌田津耶乃 データサイエンティストのための特徴量エンジニアリング Soledad Galli(著), 松田晃一(訳) 実践力をアップする Pythonによるアルゴリズムの教科書 クジラ飛行机 スッキリわかるサーブレット＆JSP入門 第4版 国本 大悟(著), 株式会社フレアリンク(監修) 徹底攻略 基本情報技術者教科書 令和6年度 株式会社わくわくスタディワール
awslim - Goで実装された高速なAWS CLIの代替品を作った - 酒日記 はてな支店
最初に3行でまとめ AWS CLIは便利です。しかし起動が遅いので、Goで実装された高速な(ただし機能は少ない)代替品を作りました。awslim といいます リリースバイナリは無駄に大きいので、必要な機能だけを組み込んだビルドを簡単にできるようにしてあります。ビルドして使うのがお勧めです どうぞご利用下さい github.com 以下はこれに至るまでの経緯とか、実装や使い方の話とかです。長いです。 作成の経緯 AWSの各種サービスにアクセスするための AWS CLI は、スクリプトやコマンドラインから処理を自動化するために大変便利なツールです。AWSでサーバーサイドの開発、運用している人であれば、ほぼ全員がお世話になっているんじゃないかと思います。 しかし、AWS CLI (コマンド名aws) には「起動が重い」という問題があるなとずっと思っていました。具体的には、aws --versio
昨年書いたサーバーサイドエンジニアとして2020年に使った技術1の2021年版となります。 昨年と同じく、冒頭の画像はwakatimeによる2021年1月1日から12月26日までのプログラミング言語使用率です。2位はTypeScript、3位はYAML、4位はTerraformです。 立場 フリーランスで、主にRailsやAWSを使用しているサービスの運用、開発に関わっています。いくつもの会社を見てきた訳ではなく、数社に深く関わっている1都合上、視野が狭いかもしれません。(昨年と同じ) 今年公開している成果については以下です。 Agones移行物語 - Kubernetes Meetup Tokyo 42 #k8sjp｜うなすけ｜note なぜ我々はクラウドゲーミング基盤をKubernetesに移行したのか #CNDT2021｜うなすけ｜note Repro のサーバーサイド開発環境を M
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS Lambdaによる進化的アーキテクチャの構築 | Amazon Web Services
ServerlessDays Tokyo 2023が最高すぎた！ - Qiita
PathtraqというLifeLogサービスを作った - たごもりすメモ
EKSからECSに移行して開発運用コストの削減を図る - KAYAC engineers' blog
Fargateの運用 ～デプロイ自動化や監視等～
エンジニアとして2020年に関わった技術をまとめる - バーチャルおりばーハウス
AWS Batch ベストプラクティスまとめ | Amazon Web Services
AWSコスト最適化の勘所のまとめ - Qiita
EC2とcronで動いていたバッチ基盤をマネージド化した - Uzabase for Engineers
AWS ファイルストレージサービスの選び方 | Amazon Web Services
AWS Copilot のご紹介 | Amazon Web Services
AWS ECS Fargate のCPU性能と特徴 | 外道父の匠
ABEJAの技術スタックを公開します (2019年11月版) - ABEJA Tech Blog
AWS Graviton2 新CPUの性能検証 | 外道父の匠
AWS を退職します👋
身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 - Findy Tools
読書メーターのインフラ構成について - BOOK☆WALKER inside
サーバーサイドエンジニアとして2021年に使った技術と来年の目標 | うなすけとあれこれ