システムをVMからコンテナに移行して、結局VMに戻した話 - MonotaRO Tech Blog
こんにちは、モノタロウ コアシステムエンジニアリング部門 配送ドメイングループの安見です。 この記事では私が関わっていた社内システムを仮想サーバ(AWS EC2)からコンテナに移行した後にコンテナをやめて仮想サーバに戻した話をご紹介します。 諸説明 コンテナ移行について コンテナ化対象システムについて 直面した様々な問題 リリース後の多数の残課題 展開する機能の数が多すぎる コンテナ化のメリットが薄かった なぜこうなったか よかったこと まとめ 追記： 現在なら... 諸説明 コンテナ移行について システムのコンテナ移行とは、アプリケーションやサービスを動作させるための必要なすべての環境を、一つの「コンテナ」としてパッケージ化して動作できるようにすることです。これにより、アプリケーションは他のシステムと独立して実行され障害分離ができたり、環境の違いによる影響を受けにくくなるため移植性が向上
「1億台の常時接続」を実現せよ！ Nintendo Switchのプッシュ通知システム全面刷新の裏側 (1/3)
アマゾン ウェブ サービス ジャパンは、2024年6月20日と21日、国内最大の年次イベントである「AWS Summit Japan」をハイブリッドで開催。150を超えるセッションが展開された。 本記事では、ニンテンドーシステムズによるセッション「Nintendo Switch向けプッシュ通知システムのリプレイス事例」をレポートする。登壇したのは、同社 システム開発部の林愛美氏と坂東聖博氏だ。 2017年のNintendo Switchの発売とあわせてリリースされた「プッシュ通知システム」。同社は、長期運用を見据えて、よりクラウドネイティブなシステムへのリプレイスを決定するが、大量のTCP接続を維持するための様々な課題が立ちふさがった。 本セッションでは、AWS FargateやNetwork Load Balancer（NLB）といったAWSのマネージドサービスを用いた、“最大1億台”級
ソフトウェアアーキテクチャメトリクスの基礎: Software architecture metrics in a nutshell
ソフトウェアアーキテクチャメトリクス - Forkwell Library #44 での発表資料です https://forkwell.connpass.com/event/309739/ 動画: https://www.youtube.com/watch?v=C52rYX_E9bA …
AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
AWSでの法令に則ったログ設計及び実装/分析 - Adwaysエンジニアブログ
エージェンシー事業でリードアプリケーションエンジニアを行なっている大窄 直樹 (おおさこ)です. AWSのログ, サーバーのログってたくさん種類があって難しいですよね... 同じようなログがたくさんあるので, 何を取れば良いのかとか どのくらいの期間保持すれば良いのかとか またその後の, ログの実装や, 分析方法する方法も難しいですよね... 今回AWSに構築した商用アプリケーションのログを整備する機会があったので, このことについて書こうかなと思います. 概要 本題に入る前の準備 今回ログ実装するアーキテクチャ ログに関する法令 ログの取得箇所 設計 保管するログの決定 インフラのログ OSのログ アプリケーションのログ ログの保管 保管場所について 保管期間について バケット構造 アプリケーション, OSのログの転送 実装 アプリケーション, OSのログをfluentbitを用いてS3
Fintan
/***************************************** { Fintan } 先進技術・ノウハウを駆使して、新しい社会の活力を創造し、人々の笑顔を増やしていく。 *****************************************/ /****************************************** { Fintanと鮭 } Fintan（フィンタン）は、ケルト神話に登場する知恵の鮭の名前です。 食べれば世界のあらゆる知恵を得ることができるとされており、これを食べた主人公はその知恵を使ってあらゆる難題を解決したと言われています。 利用者が、システム開発のあらゆる知恵を得られるようにという思いを込めて、Fintan（フィンタン）と名付けました。 ******************************************
『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』 - snoozer05's blog
翻訳を担当した書籍『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン）が3月8日に発売されます。本書は、2020年1月に出版されたMark Richards, Neal Ford著『Fundamentals of Software Architecture』（O'Reilly Media）を全訳したものです。 www.oreilly.co.jp ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや
システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
マルチテナントアーキテクチャについて - コンポツさん
SaaSシステムを開発しているみなさま、お元気でしょうか。 SaaSシステムというといわゆるWebサービスよりももう少しBtoBの雰囲気が漂ってまいります。 SaaSシステムでは契約者（ここではテナントと呼ぶ）が複数いて、テナント毎に複数のログインユーザーやロールが存在するのが一般的です。そして当然ながらテナント毎のデータは漏洩・混濁が許されない高いセキュリティが求められます。 SaaSシステムの構築はスケーラビリティにおいても100テナント程度から始まりゆくゆくは数千、数万テナントまで少なくとも線形にスケールするアーキテクチャを開発当初から求められ、さらに突発的な大規模テナントも問題なく吸収したいという要求があります。 その要求を満たす設計・開発・保守・運用をやっていくのは当然ながら簡単ではありません。 というわけで今日はマルチテナントアーキテクチャのお話です。 世に出る情報がとっても少
ソフトウェアのアーキテクチャについて - threecourse’s blog
最近、小〜中規模のプログラムを保守性高く記述するにはどうすればよいかが気になっていて、 ソフトウェアのアーキテクチャについて調べていました。 本を読んでみる 以下の本を浅めに読み通してみました。どの本もそれぞれ学ぶべき点があって興味深かったです。 .NETのエンタープライズアプリケーションアーキテクチャ第2版 https://www.amazon.co.jp/dp/B00ZQZ8JNE C#での設計の話。ドメイン駆動設計など、設計に関わるトピックが広く触れられていて良い。 Adaptive Code C#実践開発手法 第2版 https://www.amazon.co.jp/dp/B07DJ2BL4Y C#での実装の話。SOLID原則を中心に、実装に関わるトピックが広く触れられていて良い。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 https://www.a
James Lewis/Martin Fowlerの"Microservices"日本語訳 - 自由課題
はじめに 本記事はMartin Fowler氏のBlog記事を日本語訳したものです。 なお、訳は2014/11/09時点のもので、オリジナル記事中のコラムは訳せていません。コラムの訳に関しては、暇や反応を見ながらぼちぼちやろうと思います。 訳に対する指摘・ご意見などありましたらtwitter(@kimito_k)でお願いします。 補足 Martin Fowler氏に連絡をとったところ、主著者はJames Lewisであるとのことでしたのでタイトルを変更しました。(2014/11/13) Microservices "マイクロサービスアーキテクチャ"という専門用語は、ソフトウェアアプリケーションを独立して配置可能なサービスの組み合わせ(suite)として設計する特定の方法を指すものとして、ここ数年で急速に認知されています。このアーキテクチャスタイルに対する正確な定義はありませんが、ビジネス遂
SILO再考〜次世代DBのアーキテクチャとして - 急がば回れ、選ぶなら近道
大分たってしまったけど、ようやく時間が空いたので、db tech showcase Tokyo 2016 http://enterprisezine.jp/dbonline/detail/8466 で話した内容を記録的に書いておく。あとはSILOの解説を特に自分用に論文の4章を中心に整理しておく。あとはついでに自分の思うところも記す。 ・SILO 元論文はこちら、執筆陣はMITのLiskov一派とEddie Kohler 現在のDB研究の第一線のメンバー。 http://people.csail.mit.edu/stephentu/papers/silo.pdf SILO以降、大きくDBベースのアーキテクチャの考え方は変わりました。ほとんど全ての分散系OLTPはSILOを程度の大小はあるとはいえ、意識していると言っても過言ではないでしょう。前世代ではほぼ「空想か？」ぐらいの扱いだった分散t
Twelve‐Factor Appをエンタープライズに生かす
［Twelve-Factor App（12）］運用作業はスクリプトで自動化 モダンなクラウドアプリケーション開発のベストプラクティスの一つである「The twelve-Factor App」が取り上げられることが多くなった。ビジネスの変化にICTが遅れずについていくためには、エンタープライズ分野の開発も、このプラクティスを取り入れていくべきだ。本稿では、エンタープライズシ… 2014.12.05 ［Twelve-Factor App（11）］ログをまとめて利用可能に モダンなクラウドアプリケーション開発のベストプラクティスの一つである「The twelve-Factor App」が取り上げられることが多くなった。ビジネスの変化にICTが遅れずについていくためには、エンタープライズ分野の開発も、このプラクティスを取り入れていくべきだ。本稿では、エンタープライズシ… 2014.12.04 ［T
「The Twelve-Factor App」を15項目に見直した「Beyond the Twelve-Factor App」を読んだ - kakakakakku blog
2012年に Heroku のエンジニアによって提唱された「The Twelve-Factor App」は素晴らしく，アプリケーションをうまく開発し，うまく運用するための「ベストプラクティス」として知られている．2020年になった現在でもよく引用されていると思う．日本語訳もある． 12factor.net Beyond the Twelve-Factor App とは？ クラウド化が進むなど，提唱された2012年と比較すると技術的な変化もあり，今までの「The Twelve-Factor App」で宣言されていた観点以外にも必要な観点やベストプラクティスがあるのでは？という意見もある．そこで，2016年に Pivotal のエンジニアが「Beyond the Twelve-Factor App」を提唱した．The Twelve-Factor App にあった「12項目をアップデート」し，新
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
これから学ぶ人のための ソフトウェアアーキテクチャ入門: Software architecture is a tool to enhance our humanity
AWS リファレンスアーキテクチャ図
system-design-primer/README-ja.md at master · donnemartin/system-design-primer
アプリケーションアーキテクチャの現在、過去、未来