システムトラブルに強いWebフロントエンドを作る方法
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 初めに こんにちは、Yahoo!知恵袋でシステム開発を担当している村上です。 Yahoo!知恵袋（以下、知恵袋）では利用者の皆さまに快適なサービス体験をしていただくため、日々改善が行われています。しかし、サービスができる事が増える度に、コードベースや連携先が増えていくのは常であり、その変化の影響でシステムトラブルが起きることもあります。 今回は、拡張されていくシステム構成という視点で、万が一のシステムトラブルが発生した時に備えて、被害を最小限に食い止める方法を紹介します。 背景 知恵袋では、以下のようなサービス構成を取っています。 フロントエンドシステムは基本的にAPIを通じて複数のバックエンドシステムと疎通することでサービスを提
アーキテクチャ設計に品質特性を使おう - arclamp
アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報
熱量を失ったサーバーレスという世界（個人の所感） - Sweet Escape
はじめに 先日、エンジニア界隈では有名なポッドキャストであるfukabori.fmに出させていただきまして、そのときのトピックがサーバーレスでした。 ポッドキャストはこちらで聞けますのでぜひどうぞ。 fukabori.fm そこでもいろいろお話ししたのですが改めて話せなかったことなども含めて書こうかなと。つまり、ポエムです。散らかった文章な上に少し長めなのでお時間のある方だけどうぞ。 なお、サーバーレスの黎明期の話とかそういう思い出話は以前に書いたこちらの投稿があります。 サーバーレスと僕のこれまでとこれから - Sweet Escape 今回は思い出話ではなく、サーバーレスに個人として魅力を感じ、仕事としてその良さを広めたり、実装のお手伝いをし続けてきた自分がそういった仕事から離れた2022年現在どういう風に向き合ってるかについてのポエムです。 前提 現在の自分は株式会社Singular
「技術的には可能です」と発声するその前に - Qiita
技術者はよく、実装可否の問い合わせに対して本当はやりたくない・すべきでないと思っているのにやればできることだからと「技術的には可能です」と答えてしまいハマる⋯って本当ですか？ 私は最低でもここ10年は「技術的には可能です」と発言した記憶がありません。なぜそう言うことがないかというと、可否の問い合わせを受けた時点で次のようなことを考えてしまうからです。 運用は回る？ 人力操作が絡むフローがあるけど利用数が増えたときにちゃんとスケールする？ 休日深夜対応が必要になりそうだけど要員と人件費コストは確保できてる？ カスタマーサポート対応激増しそうだけど（以下同文 誤操作があったりしてデータの修正依頼が来たときに訂正しようがない要件っぽいけど大丈夫？ エンジニアがDB直操作対応するサービスメニューが存在するけど事故リスク、工数コスト、今後の開発停滞リスクは織り込み済み？ 事故の際の責任はエンジニアに
実装クリーンアーキテクチャ
最近何かと騒がしいクリーンアーキテクチャですが、丁度プロダクトで採用したところだったので折角なので情報共有ということで Qiita の初記事にしてみようと思います。 こちらの記事は GUI や CUI のアプリケーションを対象にしています。 Java コードの記事リンク：https://nrslib.com/clean-architecture-with-java/?preview_id=1263&preview_nonce=542ba7b70f&_thumbnail_id=1293&preview=true その他解説もしています。もしよろしければチャンネル登録をお願いいたします。 より実践的なコード（WEBアプリケーション）: https://github.com/nrslib/itddd/tree/master/CleanLike YouTube での解説（WEBアプリケーション）：
新しいデータ基盤アーキテクチャである「データレイクハウス」について調べてみた - Taste of Tech Topics
最近ソーダストリームを買い、炭酸水を飲むのにはまってます。機械学習エンジニアの@yktm31です。 以前に「AWS Lake Formationでデータレイク体験！」という記事を書いてみて、データ基盤アーキテクチャに興味が湧いてきました。 データレイクハウスは、「データウェアハウス」と「データレイク」を統合したようなアーキテクチャで、 2020年にDatabricks社により提唱され、新しいデータ基盤アーキテクチャとして注目されているようです。 www.databricks.com そこで今回、「データレイクハウス」について調べてみたことをまとめてみたいと思います。 なぜデータレイクハウスが注目されているのか？ データウェアハウスの特徴・課題 データレイクの特徴・課題 データレイクハウスの特徴 データレイクハウスのアーキテクチャ Azure Azure Synapse Analyticsを
1/ GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」（※少しマニアックな内容ですが、個人的には面白いと感じたので載せます→）
門脇 敦司/ Atsushi @at_sushi_ Knowledge Sense, Inc. CEO ← 東大 / エンタープライズ向け生成AIプロダクトで成長中のスタートアップ（2019年~） / ソフトウェアエンジニアを募集中（800万円~+SO）→DM開放中 / 好きな言葉は「実験と学習」/ 最新の生成AI 事情に少し詳しいです https://t.co/PwBZaT31cB 門脇 敦司/ Atsushi @at_sushi_ 1/ GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」 （※少しマニアックな内容ですが、個人的には面白いと感じたので載せます→） twitter.com/jasoncwarner/s… 2022-11-16 09:20:18 Jason Warner @jasoncwarner I'm convinced that o
ソフトウェアアーキテクトが知るべき97のこと
ソフトウェアアーキテクトが知るべき97のこと大人気の書籍『ソフトウェアアーキテクトが知るべき97のこと』のエッセイを無料で公開中！すべてのソフトウェアアーキテクトにおすすめの本がウェブで読めるようになりました。 エッセイ一覧システムの要件よりも履歴書の見栄えを優先させてはならない本質的な複雑さは単純に、 付随的な複雑さは取り除け最大の問題は、たぶん技術的なことではないまずコミュニケーション、そのための明快さとリーダーシップパフォーマンスの決め手はアーキテクチャー要求仕様の本当の意味を探れ立ち上がろう!すべてのものは、かならずエラーを起こすそれは交渉だということに気付け定量化を求めよ500行の仕様書より1行のコードフリーサイズのソリューションを求めるなパフォーマンスの検討に早過ぎるということはないアーキテクチャーとはバランスをとること犯罪的なコミットエンドラン
バッチ処理 プラクティス
バッチ処理は既に先人の方々が多くのナレッジを公開してくれていますが、それでもなお難しさが変わらないテーマだと思っています。 この記事は、筆者がこれまでの開発経験で気づいたバッチ処理の実装ナレッジを整理し、体系化を目指して文章にしました。 ここでの内容が、より良い課題解決に貢献できれば幸いです。 自身の断片的な思考整理(メモ書き)の延長で内容を整理したため、一部書き振りが統一されておらず、読みにくいかもしれません。ご了承ください。🙏 バッチ処理の難しさバッチ処理は難しい。 人によっては簡単なテーマかもしれませんが、自分は難しいテーマだと思っています。 「難しさの根源は何か？」を考えると、1. 考慮点が多様にあること 2. 解決する課題によって答えが大きく変わること に整理できました。 この2点は、どのソフトウェア開発にも当てはまる項目ではありますが、ことバッチ処理においては顕著に現れます。
DynamoDBの難しさについて - Qiita
はじめに DynamoDBは上手く使えば非常に強力なDBMSですがRDBとの違いは大きく、「RDBの代わりにDynamoDBを使おう！」と深く考えずに提案/採用することが難しいことから、その理由についてみていきます。 DynaomoDBの難しさ DynamoDBの利点と表裏一体である、DynaomDBの主要な難しさについて順番に見ていきます。 1. 提供されているクエリモデルでできることが非常に限定されている DynamoDBは次の公式サイトに記載がある通り、どんな規模でも数msの一定のパフォーマンスを発揮でき、無尽蔵にスケールできるという特徴があります。 Fast, flexible NoSQL database service for single-digit millisecond performance at any scale この特性を上手く活用すると次の実例のように高可用性、
ソフトウェア設計原則は変更容易性に通ず - Shin x Blog
色々な原則や方法論はあれど、つまるところいかに変更容易性を確保するかと言う話に帰結するのでは。極論すれは、正しく動いていて変更する必要が無ければどのような作りになっていても構わない。一方、Web アプリケーションを稼働し続ける上で全く変更しなくて良いということもない。— Masashi Shinbara (@shin1x1) 2021年5月30日 ソフトウェア設計、開発には多くの原則や方法論がある。例えば、DRY 原則や SOLID 原則、デザインパターンにレイヤードアーキテクチャ、クリーンアーキテクチャなどある。さらに DDD にも多くの原則や方法論が含まれている。これらを変更容易性を高めるための手段として原則や方法論を捉えるというのが本エントリの論旨である。 原則や方法論の捉え方 変更容易性 本質的な変更と副次的な変更 外部変更容易性と内部変更容易性 原則を適用する指針 さいごに 原則
Microsoft の「クラウドアプリケーションのベストプラクティス」が良かったので紹介したい | DevelopersIO
こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。 最近調べものをしている中で見つけたドキュメントが良かったのでご紹介したいと思います。 先にまとめ Microsoft の RESTful Web API の設計 のドキュメントが API 設計を考える上で勉強になった 関連する クラウド アプリケーションのベスト プラクティス のドキュメントもアプリケーションを設計する際の指標として良さそう RESTful Web API の設計 最近 API 設計やパス設計について考える機会があったのですが、これという正解がなかったり、人によって思想やこだわりが違ったりして結構難しいなと感じていました。 そんな中で下記のドキュメントを見つけてひとつの指標として良いなと思ったのでご紹介します。 内容（項目） REST とは何か リソースを中心とした API 設計の整理 HTTP
ブラウザで動くサービスを作るときの技術選定
はじめに 私の仕事は、新規サービスをまるっといい感じに開発するのを委託されることがほとんどです。最近はネイティブアプリを作ることよりもブラウザで動くWebサービスを開発することが多いのですが、案件の規模感や要求によって技術選定を少し変えるようにしています。「こういうときはこう」みたいに一概には言えないのですが、普段使う構成を紹介します。誰かの参考になれば幸いです。 2022/02/10 現在での内容です。 前提 開発を委託される場合の運用費をどうするの問題があります。クライアントにクレカ登録をしてもらうか、こちらで支払って毎月請求するかになります。僕は毎月やるのがめんどくさいのでできるだけ前者に倒している関係上、あまりいろいろなSaaSを組み合わせて作ることをなるべく避けています。 規模感によらず使っているもの 私の場合、以下が使えるとめちゃくちゃ効率よく開発できます。 GCP 好きだから
良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
今後は「データ指向アプリケーションデザイン」を考えよう(Red Hat Forum講演フォローアップ記事) - 赤帽エンジニアブログ
Red Hatの須江です。 本記事は赤帽エンジニア Advent Calendar 2019の10日目です。 子供を皮膚科に連れて行ったりなんだりで、気づいたら12/11になってますが、細かいことは気にせず進めます。 セッション資料と動画 redhat.lookbookhq.com redhat.lookbookhq.com 「データ指向アプリケーションデザイン」をメインテーマに選んだわけ デジタルトランスフォーメーション(DX)がバズワード化して久しいですが、自分は常に「DXは目的ではなく手段なので、DXしたあとにどうありたいかのビジョンを持ち、そこから逆算していまやることを考える」ことが重要だと考えています。 ビジョンを持つためには、まずDX後の世界がどうなっているのかをイメージできるようになる必要があります。 そこで、2019/6/20に開催された「DX&Open Hybrid Cl
これまでにないほど「技術の目利き」が必要な時代 クレディセゾン小野氏・ウルシステム漆原氏・ソラコム玉川氏が説く判断基準
テクノロジーやビジネス潮流への豊富な知見を持つ登壇者ら 司会：モデレーターは、株式会社サーバーワークス代表取締役社長・大石良様にお願いいたします。それでは大石様、よろしくお願いいたします。 大石良氏（以下、大石）：みなさん、こんにちは。このすばらしい「SORACOM Discovery2019」も、いよいよクロージングセッションになりました。タイトルは「バズワードを超えて 〜テクノロジー・ビジネス潮流の見極め方〜」ということで、テクノロジーやビジネス潮流の見極めに長けた3名の達人をお招きして、進めていきたいと思います。おもしろい内容がありましたら、ぜひ「#discovery2019a」でつぶやいていただけたらと思います。 では、改めてご紹介させてください。ゲストスピーカーのお三方をお招きしております。自己紹介は、それぞれ30秒ということで。 （会場笑） 小野さんからお願いできればと思います
Ruby on Railsの正体と向き合い方 / What is Ruby on Rails and how to deal with it?
Rails Developers Meetup 2019（2019/03/22 - 23）
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェアアーキテクチャの基礎: Software Architecture in a Nutshell
本当は恐ろしい分散システムの話
