SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。
SaaS アーキテクチャ概要
SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。
レイヤードアーキテクチャを振り返る - Sansan Tech Blog
こんにちは、Sansanプロダクト開発部の清水です。 ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。 そもそもレイヤードアーキテクチャって何? 概要 一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。
アーキテクチャオタクが Twitter の内情について妄想を垂れ流す
Yuta Okamoto @okapies Twitter のような巨大な分散システムが、どのくらいの人員がサボタージュしたら壊れるかなんて外からは分からないし、何だったら中の人間にだって分かってないかも。イーロン・マスクも含めてね。色々な可能性を考慮しつつ推移を見守るしかない。 twitter.com/100poisha/stat… 2022-11-19 17:38:11 ざんねん @100poisha Twitterのコア開発者が辞めたのでTwitter終了←まちがい Twitterのコア開発者が辞めたので代わりの開発者を雇わないと数年で終了←せいかい ソフトウェアは腐りますけど、だからといってメンテナンスしないと1日で腐り果てるほど脆くないんですよ。そのせいでメンテナンスせずに数年経って腐り文字数 2022-11-18 14:47:09
ゼロトラストアーキテクチャ 適用方針
ゼロトラストアーキテクチャ 適用方針 2022 年（令和 4 年）6 月 30 日 デジタル庁 〔標準ガイドライン群ＩＤ〕 DS-210 〔キーワード〕 ゼロトラスト、ゼロトラストアーキテクチャ、 〔概要〕 政府情報システムのシステム方式について、より堅牢なシステム構築の観 点からゼロトラストアーキテクチャの適用方針を示す。 改定履歴 改定年月日 改定箇所 改定内容 2022年6月30日 初版決定 i 目次 １ はじめに ......................................................... 1 １.１ 背景と目的 .................................................. 1 １.２ 適用対象 .................................................... 1
『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』 - snoozer05's blog
翻訳を担当した書籍『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン）が3月8日に発売されます。本書は、2020年1月に出版されたMark Richards, Neal Ford著『Fundamentals of Software Architecture』（O'Reilly Media）を全訳したものです。 www.oreilly.co.jp ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや
クリーンアーキテクチャ完全に理解した
clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心
SaaS系スタートアップのリアルなAWSアーキテクチャ設計
概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel（最近資金調達しました！記事はこちら）で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト（リソース・運用） ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論（アーキ
さよならアーキテクチャ議論｜Seiji Takahashi@ベースマキナ
ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん
DX時代のITアーキテクチャー、7階層ですっきり理解
DX時代に求められるITアーキテクチャーの構成は複雑なことが多く、必要な要素技術や設計・開発手法も多岐にわたる。その全体像を把握するのは困難に思えるが、以下のように7階層に分けて考えると理解しやすい。 ●DXを支える7階層のITアーキテクチャー （1）チャネル層 （2）UI／UX層 （3）デジタルサービス層 （4）サービス連携層 （5）ビジネスサービス層 （6）データサービス層 （7）データプロバイダー層 今回はこの図を基に、7階層のそれぞれの特徴とDX移行時に押さえるべき要素技術や仕様、よくある課題について順番に見ていこう。 （1）チャネル層はユーザーとの最初の接点 ユーザーとサービスとの最初の接点となる部分の階層。パソコン、スマートフォン、タブレットなどの端末、そこからアクセスするアプリケーション（Webブラウザー、チャットボット、SMSなど）の他、コールセンターなどの顧客サービスもチ
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
Webシステムアーキテクチャの地図を描く構想 - ゆううきブログ
この記事は第5回Webシステムアーキテクチャ研究会の予稿です。 はじめに Webサービスにおいては、スマートフォンの普及によるアクセス増加に対してスケーラビリティを持ち、個人向けだけでなく企業向けサービスの可用性の要求に耐えられるようなシステム設計が必要とされている。 さらに、Webサービスが人々の生活に浸透したために、Webサービス事業者はサービスを長期間運用することが当たり前となっている。 その間、新機能開発、ソフトウェアの実行効率化、セキュリティ向上などを目的に、システム管理者は自身が管理するソフトウェア群を更新しつづける必要がある。 このような多様な要求を満たすために、Webサービスを開発・運用するエンジニアには、OSやデータベース、ネットワーク、分散システム、プログラミング言語処理系などのコンピュータ工学における広範囲の基礎知識と、ミドルウェア、オペレーション自動化のためのソフト
サーバーレスアーキテクチャ再考 - ゆううきブログ
2014年にAWS Lambdaが登場し、Functionを単位としてアプリケーションを実行する基盤をFunction as a Service(以下、FaaS)と呼ぶようになった。 そして、同時にサーバーレスアーキテクチャ、またはサーバーレスコンピューティングと呼ばれる新しいコンセプトが普及するに至った。 当初、そのコンセプトが一体何を示すかが定まっていなかったために議論が巻き起こり、今現在では一定の理解に着地し、議論が落ち着いているようにみえる。 しかし、サーバーレスという名付けが悪いということで議論が着地したようにみえていることにわずかに疑問を覚えたために、2019年の今、これらの流れを振り返ってみて、サーバーレスアーキテクチャとは何かを改めて考えてみる。 サーバーレスとの個人的関わり サーバーレスアーキテクチャという名を僕がはじめて耳にしたのはAWS Lambdaが登場した2015
ソフトウェアアーキテクチャの歴史 - tasuwo's notes
改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。本来の MVC とは何か？何が正しくて何が間違っているか？も重要なのだが、それよりは、なぜそれが生まれたのか？何を解決しようとしたのか？どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか？を知りたい。しかし、そういうことがまとまっている日本語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M
なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。 拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。 本記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで
Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLとMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ
マイクロサービスはもう十分 | プロダクト・サービス | POSTD
モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Goのクリーンアーキテクチャで参考になりそうなもの
なぜもっとたくさんのコアを搭載したCPUを作らないのでしょうか？2000コアのGPUなんかそこら辺にありますが、なぜCPUでは同じようにできないのでしょうか？
マイクロカーネルの設計と実装
知っているようで知らないWebサーバアーキテクチャ
