円安を乗り越えるための Arm アーキテクチャへの移行が完了！ そのプロセスを公開します - カミナシ エンジニアブログ
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは、クラウドインフラストラクチャに AWS を採用していますが、昨今の円安を受けて円換算での請求額は右肩上がりで増え続けています。サービスの規模や特性に関わらず、パブリッククラウドを利用する多くの日本企業で頭痛の種になっているのではないでしょうか。 円安になる前から継続的にコスト最適化には取り組んできましたが、クイックウィンで実施できるものはやり尽くしており手詰まり感がありました。しかし、我々スタートアップにおいて適正なコストに抑えることはランウェイ（キャッシュ不足に陥るまでの残存期間）を伸ばす意味でも重要なため、現状に甘んじることなく次の最適化ポイントを探していました。 Arm アーキテクチャ移行によるコスト最適化への期待値 AWS は Arm ベースの Graviton プロセッサを開発しており、
ECS Fargate の ARM64 版は長らくスポットが使えませんでしたが、ようやくやってきました。 利用するにあたって、いくつかポイントと注意点があるので、ザックリと把握しつつ自分用にどう構成するかを考えていく感じになると思います。 はじめに リリースや価格についてはこちらにまとまっています。 [アップデート] Fargate Spot で AWS Graviton ベースのコンピューティングがサポートされました | DevelopersIO 東京だとオンデマンドに比べて 62% OFF くらいです。前は Blue/Green の場合にスポットを利用できませんでしたが、今は解消されドキュメントからもその記述は消えています。 落ちやすさはまだわかりませんが、EC2 の例だと X86 より ARM64 の方が安定している雰囲気があるので、Fargate においても速い・安い・安定を期待で
Railsのマイクロサービスアーキテクチャで構成されたアプリをモノレポ構成に移行した話 - Sansan Tech Blog
こんにちは。技術本部Sansan Engineering Unit Master Data Groupの古本です。 普段は、営業DXサービス「Sansan」の名刺交換した人や企業に関するニュースを表示し、お知らせする「企業ニュース」や「企業情報」を扱うシステムの開発をしています。 最近、マイクロサービスで作られた企業ニュースのシステムをモノレポ構成に移行しました。 今回はその時に行ったことについて話します。 モノレポ（mono repo）とは 本ブログで類似の記事があったので引用します。 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 今回も複数レポジ
踏み台サーバーをEC2からECSに移行してオンデマンド起動してみた - Nealle Developer's Blog
こんにちはSREチームの宮後(@miya10kei)です。最近、iPad Air(M2)をゲットしたので便利な使い方を模索しています。 みなさんは踏み台サーバをどうやって構築していますか？ 今回、EC2で構築していた踏み台サーバーをECSに移行することでセキュリティ向上 x 運用負荷低減 x コスト削減をおこなうことができたので紹介したいと思います。 背景 弊社ではローカルPCからAurora or ElastiCacheに接続する際の踏み台サーバーをEC2で構築していました。最近、システムのセキュリティ向上の活動をおこなっていく中で踏み台サーバーに対して以下の課題感を持つようになりました。 EC2をパブリックサブネットに配置していたのでプライベートサブネットに配置することでよりセキュアな構成にしたい EC2のOSアップデートなどのEC2に起因する定期運用を削減したい 踏み台サーバは24時
こんにちは。サーバーサイドエンジニアの @atolix_です。 今回は37signalsが公開しているThrusterを、メドピアで本番運用をしているアプリケーションのkakariに導入してみました。 kakari.medpeer.jp Thrusterとは Thrusterはアセット配信やX-Sendfileのサポートといった機能を持ったGo言語製のHTTP/2プロキシです。 詳細な設定不要でRails標準のPumaサーバーと組み合わせて動作して、nginxを構成に加えた時と同様のリクエスト処理を行うことが可能です。 github.com www.publickey1.jp 導入前の状況 導入以前のkakariは以下のような構成を取っていました。 アセット配信の為にALBの背後にnginxを置いています。 今回は管理コストを下げる為に、nginxを剥がしてThrusterからアセット配信
NetBox のオンプレから Amazon ECS 移植を CDK で実現する - NTT Communications Engineers' Blog
チームの管理情報を溜めていたオンプレ基盤で動く NetBox を Amazon Elastic Container Service へ AWS Cloud Development Kit を用いて移植しました。 今まで NetBox をオンプレで動かしていた際には以下のような運用の難しさがありました。 DB も Docker コンテナによって管理されており、冗長化もなかったため DB コンテナが落ちてしまうとサービス提供できなくなる可能性があった Docker Compose で動かしているので、サービスの作り直しを実施するとそれまでのログが削除される そもそも NetBox を動かしている場所で法定停電があり、定期的に NetBox のサービスがとまっていた NetBox を AWS へともっていくことでオンプレ運用時に発生していた手間を簡素化し、メンテナンス等も一部 AWS にマネージ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS ECS ARM64 FARGATE_SPOT 利用上のポイント | 外道父の匠
RailsアプリケーションにThrusterを導入する - メドピア開発者ブログ