公開日 2024/05/28更新日 2024/07/25注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット エアークローゼットは日本初・国内最大級、女
AIに仕事を奪われないために、自分の発想を強化していかないといけない 服部佑樹氏（以下、服部）：次に行きたいと思います。「エンジニアとAIの関わり方」ですね。AIが登場したことによって、どういうかたちでエンジニアが変わっていくのか。概念としてはものすごく広いですが、みなさんもいろいろな観点の捉え方があると思っています。 組織としてどうするのかはその次の質問になりますが、あとはキャリアとしてとか、次のポジションをどうしようかなみたいなところも含めて、個人の観点なども含めて答えてもらえるといいんじゃないかなと思います。では黒崎さんからいいですか？ （スライドを示して）3番目の質問「エンジニアがAIと協力して新たなアイデアを生み出すための効果的なアプローチ」ですね。あとは2番も合わせていいかもしれませんが、アプローチと潜在的な力を引き出すためのスキルをどうやって学んでいったらいいと思いますか？
はじめに 2023年4月に基盤エンジニアとして Ubie に入社しました nerocrux です。主に Ubie の ID 基盤の開発と保守運用を担当しています。 この記事は、2023 Ubie Engineers アドベントカレンダー 5 日目の記事となります。 Ubie では、モジュラモノリスを採用しつつ、マイクロサービスアーキテクチャも採用しており、領域によってサービスを分けて、それぞれの担当チームが開発と保守運用をしています。 クライアントから一つのリクエストを受け取ったあとに、Ubie のバックエンドではリクエストを受け取ったサービスだけがそのリクエストを処理することもあれば、別のサービスにディスパッチし、複数のサービスがひとつのリクエストを処理して結果を返すこともあります。 マイクロサービス間の通信が Ubie の内部で発生したとしても、必ずしも無制限で自由に行われていいわけで
タイミーのRailsアプリをシニアなエンジニアが採点したらだいぶ辛口だった - Timee Product Team Blog
この記事はTimee Advent Calendar 2023シリーズ 1の1日目の記事です。 はじめに こんにちは、タイミーでバックエンドエンジニアをしている須貝（@sugaishun）です。昨年は弊社でアドベントカレンダーに取り組んだか覚えていないのですが、今年はなぜかいきなり3トラックで臨むということで、非常に勢いがあるなと思いました。量と勢いで攻めていくところが弊社らしいなと感じています。全て完走できると良いですね。 さて私はその中のひとつのトップバッターということで、タイミーのRailsアプリケーションについて弊社のシニアなエンジニアたちと雑談した内容を座談会風にお伝えできればと思います。事の発端は弊社Slackのバックエンドエンジニアが集まるチャンネルで「タイミーのRailsアプリケーションの健康度はどのくらいなのか？」という会話をしたことでした。その時の私の感想は「人によって
公開日 2024/06/19更新日 2024/07/25身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 多くのIT企業では、ユーザーに対してより高品質で安定した体験を提供するために、システムアーキテクチャを進化させ続けています。 本特集では、日常生活の中で多くのユーザーに利用されているサービスのアーキテクチャ設計に携わるエンジニアの方々から、技術選定の背景や意図、そして現在のアーキテクチャの課題から未来への展望まで、詳しく伺いました。この記事を通じて、各企業のエンジニアたちがどのように技術的な課題を克服し、システムの柔軟性と効率を高めているのか、知見を得ていただければ幸いです。 ※ご紹介は企業名のアルファベット順となっております アソビュー株式会社 アソビュー株式会社では「遊び」という領域に対し、マーケットプレイス型EC「アソビュー！」やD2C型SaaS
食べログのモジュラモノリス化戦略
「10年超えRails開発の振り返りと未来 - 持続可能な開発の具体策｣の発表資料です https://pieceofcake.connpass.com/event/324722/
『設計ナイト2024【オフライン】 - connpass』に参加してきたのでそのメモです。 各発表の感想 ※資料スライドは見つけたら貼ります。 ロジックから状態を分離する技術 今日の登壇資料です。 ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobodyhttps://t.co/XxBNAYiKXS #sekkeinight— わいとん (@ytnobody) 2024年6月14日 感想 純粋関数の話を基軸にいかに容易にしていくのか、という話 入力から必然的に出力が決まるロジック類をDomainとしておこうという発想はよかった 純粋関数の構成デザインパターンの分け方すごくいいなぁと思ったのと、このあたりの話を提唱している人いないのがびっくり 関連リンク 純粋関数とは - 意味をわかりやすく - IT用語辞典 e-Words Flux パターンが解決した課題 -
この記事はUbie Engineering Advent Calendar 2023の一日目です。よろしくお願いします。 背景 ユビーのシステムは言語が多様化してきたことにより、認知負荷の増加や運用負荷の増加、開発支援に仕組みづくりかけるコストの増加などの問題が発生していました。この課題を解決するためにNode.jsとGoに言語を絞っていくという意思決定をしたのが昨年です。これについては以下の記事で詳しく解説しています。 ちょうど去年のアドベントカレンダーの記事なのでこれから一年経ちました。ここでは以下のように述べられています。 Server-Side Kotlin などで書かれている既存サービスを、この技術選定の文脈でリプレイスすることは今のところ考えていません。 ただし、多くの既存サービスはドメインたくさん抱えすぎ問題があったり、色々とレガシーだったりして、徐々に別サービスに切り出して
前回の記事ではチーム中心の組織づくりの設計原則について書いた。今回は、それらの原則に基づくチームをソフトウェアプロダクト組織内にどう配備し、どのような機能を持たせるかについて考える。これは言わば、チームの責務を定義することに他ならない。本記事ではこれを、7つのガイドラインとして書き出してみることにした。 前回の記事：『チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog』 mtx2s.hatenablog.com 1. ストリームアラインド 2. オーナーシップ制 3. バリエーション分割 4. 技術横断型 5. DevOps 6. 機能横断型 7. マルチスキル 組織設計とはアーキテクティングである 1. ストリームアラインド ソフトウェアプロダクト組織の開発フローは、ユーザーや市場の観察をもとにアイデアを生み出すことから始まる。そのアイデアを仮説として、それを
2023/11/19(日)で開催された JSConf JP 2023に関する、現時点での公開資料と X アカウントリンクをまとめました。 よろしければご活用ください。 はじめに 登壇者名は敬称略させていただいています。 x アカウントについては、以下のように確認できたものを記載しております。 JSConf JP 公式サイトに記載がある JSConf JP 公式サイトに記載のプロフィールと一致している 当イベントで登壇されることに言及されている スライドに記載されている リンクの間違い等ありましたらコメントいただけると助かります🙏 アーカイブ 本イベントは YouTube で配信されていましたが、執筆時点ではトラック A の動画が非公開になっていました。 アーカイブとして残るのかがわからなかったため、一旦 JSConf JP の YouTube アカウントへのリンクのみ記載にしておきます。
はじめに こんにちは、バックエンドエンジニアの@zawaです。 私は入社以来、1年ほどショップオリジナルの「メンバーシップ」（会員制度）を開設できる「メンバーシップApp」の開発に携わってきました。 少し前になりますが、2024年2月末にメンバーシップAppの特典交換機能をリリースしました。 リリース内容の詳細はぜひこちらをご覧ください！ baseu.jp メンバーシップAppは、モジュラーモノリスのアーキテクチャ上に構築しており、モジュール内部ではドメイン駆動設計（以下、DDD）を採用しています。 先日公開された動画の中でも紹介していますので、ご興味がある方は是非ご覧ください。 【前編】クリーンアーキテクチャの柔軟性を生かしたメンバーシップAppの開発の道筋 - YouTube 【後編】クリーンアーキテクチャの柔軟性を生かしたメンバーシップAppの開発の道筋 - YouTube 本記事で
「【ハイブリッド開催】Rubyで追求するモジュラモノリスの可能性」は、バックエンドにRubyを採用している株式会社タイミー、hacomono社、ワンキャリア社が、Rubyにおけるモジュラモノリスの可能性や良い点、悪い点を共有する勉強会です。ここで株式会社タイミーの須貝氏が登壇。まずは、Railsでモジュラモノリスを実現する3つの代表的パターンと、各パターンの評価について話します。 須貝氏の自己紹介 須貝俊 氏：では、「RailsでModular Monolithを選択された御社に質問したいN個の疑問」というタイトルで発表をしたいと思います。 （スライドを示して）まずは自己紹介をしたいと思います。須貝と申します。タイミーには、2022年1月からジョインしています。スポットワークシステム領域というところで、チーム名がIronBank Squadという、企業さま向けの請求や、ワーカーさまへの給与
はじめに BASEのProduct Dev / Feature Dev1 GroupでアプリケーションエンジニアをしているTorataです。 BASEに入社して早くも3ヶ月がたちました。 少しづつBASEの仕事や環境、文化にも慣れてきたので振り返りを兼ねて入社エントリーを書こうと思います。 BASEに興味を持っている方の参考になれば嬉しいです！ 入社の経緯 前職では、新卒から約5年間、バックエンドエンジニアとして働いていました。 周りには信頼できる素晴らしい方々が多く、幅広い経験をすることができました。 ただ自身のキャリアを考えたときに、より大きなチームで大規模なシステムを扱う経験を積みたい、その中でさらにエンジニアとしての専門性を高めていきたいと思い転職を決意しました。 BASEに入社した理由は、ビジョンに共感し、成長できる環境が整っていると感じたからです。BASEのプロダクトは「個人や
はじめに こんにちは、マッチング領域でバックエンドエンジニアをしているぽこひで ( @pokohide ) です。 タイミーのアドベントカレンダー2日目の記事です。 今回は、タイミーのプロダクト組織で毎週開催している技術的な雑談を行うテックトークの紹介をします。なぜ開催しようと考えたか、どのように運用をしているかなどをお話しします。 はじめに 開催の背景 毎週ゆるく開催するテックトークについて テックトークの仕組み化 会の説明や目的の共有 WINの共有 ポストモーテムの学び共有 雑談タイム やってみて さいごに 開催の背景 タイミーのプロダクト組織では、働き方の柔軟性を担保する観点などからフルリモートという働き方を選択しています。また、タイミーではチームトポロジーを採用しており、それに沿ってチーム構成などを考えています。 チームトポロジーの変遷や取り組みについてはCTOとCPO（発表当時は
「【ハイブリッド開催】Rubyで追求するモジュラモノリスの可能性」は、バックエンドにRubyを採用している株式会社タイミー、hacomono社、ワンキャリア社が、Rubyにおけるモジュラモノリスの可能性や良い点、悪い点を共有する勉強会です。ここで株式会社hacomonoの志賀氏が登壇。まずは、モジュラモノリスを導入する前の状況と、モジュラモノリスを選んだ理由について話します。 志賀氏の自己紹介 志賀誠氏（以下、志賀）：みなさん、こんにちは。 会場：こんにちは。 志賀：うれしい、返事がきた（笑）。オフラインで話すのが久々すぎて声が出るかちょっと心配だったんですが、なんとかなりそうなのでやっていきたいと思います。 今日お話しする内容ですが、「hacomono TECH BLOG」で事前に書いた内容と若干かぶるところがあるので、もし読んだ方がいたら、おさらい程度だと思って目をとおしてもらえると幸
「【ハイブリッド開催】Rubyで追求するモジュラモノリスの可能性」は、バックエンドにRubyを採用している株式会社タイミー、hacomono社、ワンキャリア社が、Rubyにおけるモジュラモノリスの可能性や良い点、悪い点を共有する勉強会です。ここで株式会社ワンキャリアの田中氏が登壇。続いて、課題についてこれからどういうことをやっていきたいかについて話します。前回はこちらから。 横に割ってダメなら縦に割りましょう 田中晋太朗氏：ここまでで試したこと、現状の課題の話をしてきたわけですが、じゃあここまでの課題を踏まえて、今後、私がどういうところを模索していこうかなと思っているかというところについて少し話させてください。 ここまでの話とこの会の趣旨で完全にわかることなんですが、水平分割をやってきた次に何をすべきかというと、垂直分割ですね。横に割ってダメなので縦に割りましょうという話で、モジュラモノリ
この記事は 食べログアドベントカレンダー2023 の25日目の記事です🎅🎄 はじめに こんにちは、食べログシステム本部長の京和です。今年も🐓を務めさせていただきます（5年目）。 さて、今年のアドベントカレンダーの記事を改めて眺めてみると、技術的なトピックだけでなく、プロダクト開発やQA・テスト、マネジメントに関する記事など、幅広いトピックがあるなあと感じました。2018年や2019年のアドベントカレンダーを見てみると、その差がよく分かりますね。組織の変化が感じられてとても嬉しく思います。 本記事では食べログエンジニア組織の2023年振り返りとしていくつかのトピックに分けてご紹介していきます。 1. 食べログ事業について まずは事業についてです。食べログは2023年Q2(7月-9月)の決算において、初めてコロナ禍前の売上を超えました。 「株式会社カカクコム 2024年3月期 第2四半期
「【ハイブリッド開催】Rubyで追求するモジュラモノリスの可能性」は、バックエンドにRubyを採用している株式会社タイミー、hacomono社、ワンキャリア社が、Rubyにおけるモジュラモノリスの可能性や良い点、悪い点を共有する勉強会です。ここで株式会社hacomonoの志賀氏が登壇。続いて、モジュラモノリス実現のための取り組みについて話します。前回はこちらから。 モジュラモノリスを導入に向けて境界分けをどうするか 志賀誠氏：じゃあ今度は、モジュラモノリスの実現の方法について説明します。（スライドを示して）Railsでモジュラモノリスを導入するにあたって、パッと思いつくもので、このスライドにあるような問題があるかと思います。 1個は、やはりRailsはRubyなので、なんでも書けちゃうということがあると思います。もうやろうと思ったらいくらでも越境できちゃう境界区域とかがあると思います。 も
RubyKaigi 2024に参加してきました。 今回参加までに紆余曲折あったので、一時は参加を諦めていたんですが、何とか無事参加することが出来ました。 2011年に初参加して以来休まず参加していたので、ついに連続参加が途絶えるのかと思ってましたが、無事連続参加を達成できて嬉しい限りです。 今回はそういう事情もあってか、コミュニティとの繋がりを強く感じることができたRubyKaigiでした。 色々思いが溢れてしまって、技術的に楽しかったこと、自分が嬉しかったこと、参加前の事情とか全部書いてたらえらい分量になってしまいました。気が向いたら目に付いたところだけ読んでくださいw 参加前 そもそも何があったかというと、大体去年の12月ぐらいから咳が止まらなくなり、更に年明けぐらいに高熱が出た上で咳が出続けている状態でした。 余りに咳が酷かったので、喉に傷が付いた後胃酸が逆流したりして声帯の近くに潰
STORES 予約 でエンジニアリングマネージャーをしている Natsume です。 STORES 予約 は10年モノの45万行、380テーブルある大きなモノリスの Rails アプリケーションです。 業種にとらわれない汎用的な予約システムであり、それらに対応するように複雑なコードベースになっています。また、ここ 1~2 年はプロダクト間連携を進めており、各基盤やアプリケーションともつなげていく開発を進めています。今後も新規プロダクトとの連携や機能開発を進めるには、少しでも認知負荷を上げずに開発しやすい状態を保ち続けるか、が重要だと感じました。 その課題感の中で、今回はモジュラモノリスを選択し導入をしましたので、そちらのお話をしたいと思います！ 現状の課題感 私が入社した3年前から STORES 予約 の開発メンバーは3倍になり比較的新しいメンバーが多く、また古くからいるエンジニアも少数な
Ubie Engineering Advent Calendar 2023 の22日目の記事では、Ubieのプラットフォームで生じていた課題と、それを解決するためにサービステンプレーティングツールを開発・導入した取り組みについて紹介します。 はじめに プラットフォームエンジニアリングとは 具体的な課題 解決法 具体例 実装 CUE CI/CD マニフェストの更新 サービスカタログ ubieformの現在と今後 おわりに おまけ はじめに アドカレ初日の記事で紹介があったように、Ubieではモジュラモノリスとマイクロサービスアーキテクチャの両方を採用しており、独立して動くサービス数は現在70近くに及んでいます。それらのインフラの大部分はGoogle Cloud上のGKEかCloudRunで動いており、その管理と運用が私の所属する基盤チームの責務になります。 新たなマイクロサービスを立ち上げる
ログラスのバックエンド技術スタック2023
はじめに こんにちは、ログラスの小林(@mako-makok)です！ 昨日は@asa_kossyさんの「ログラスのプロダクトマネージャーチームが今年取り組んだこと、いま苦労していること 2023」でした。 ログラス社はありがたいことに、 CTO 協会主催の「開発者体験が良い」イメージのある企業で 25 位にランクインさせていただいております。 この結果は非常に光栄だと思っており、自分が想像する要因としては DDD、スクラム、技術的投資の 3 点だと思っています。 これらは継続的に活動しています。 ライブラリバージョンアップは欠かさずやりますし、DDD に関しては社内で DDD という言葉はもうほぼ使われていないレベルで浸透しており、機能追加の際はドメインエキスパートと会話つつ、モデルと実装を行き来して開発しております。 この認知は非常に嬉しい結果ではありますが、実際は開発者体験に課題を感じ
はじめに 先日、開発していたマーケティングSaaSをようやくリリースすることができました。以下、サービスページ： サービスの詳細な説明や顧客ターゲットなどはここでは省きますが、一言で表現すると、ワンクリックで様々なマーケティングデータを一元管理できるプロダクトになっています。 このプロダクトでは、初期からモジュラモノリス設計を採用し、その選択は結果的には良かったと感じています。この記事では、シード期からモジュラモノリスを選択した経緯と、その所感を書きたいと思います。 モジュラモノリスを採用した経緯 モジュラモノリスとは モジュラモノリスとは、アプリケーション全体が一つのコードベースやプロジェクトとして管理され、単一のアプリケーションとしてデプロイされるが、その内部はモジュール化されているアーキテクチャのことです。各モジュールは独立して開発・保守され、特定の機能を担当しますが、デプロイメント
巨大なモノリシック Rails アプリケーションの マイクロサービス化戦略 / 2019 microservices in cookpad
背景 著者が開発に携わるサービスは拡大期にあり、リアーキしてモノリスからモジュラーモノリス化しようと計画している。 著者はモジュラーモノリス化することで著書・チームトポロジーで描かれるようなストリームアラインドチームができていく、という理想を抱いていたのだが、どうもそれにはハードルがあるように感じたので、課題感を言語化し、それにどう対処していくかを考えた。 チームトポロジー的理想と、それに対する課題 ▼理想 逆コンウェイ戦略によりモジュール分割され、そこに必要な職能のメンバーが集まってストリームアラインドチームができる。エンジニアの認知負荷は減少し、コミュニケーションや意思決定はチーム内で完結し、アウトカムが最大化される。 ▼課題 「PMによる日々の施策立案は、現在想定しているモジュールに閉じた形ではなされていない」という現実がある。このままでは、モジュール分割を達成しても、各プロジェクト
「【ハイブリッド開催】Rubyで追求するモジュラモノリスの可能性」は、バックエンドにRubyを採用している株式会社タイミー、hacomono社、ワンキャリア社が、Rubyにおけるモジュラモノリスの可能性や良い点、悪い点を共有する勉強会です。ここで株式会社タイミーの須貝氏が登壇。続いて、タイミーがどうやってモジュラモノリス化を進めているかについて話します。前回はこちらから。 タイミーが抱えていた課題 須貝俊 氏：続いて、タイミーがどうやってモジュラモノリス化を進めているかというところをより具体的に話していきたいと思います。 （スライドを示して）課題としてはスライドに示したようなものがあって、コード上で何が何に依存しているのか把握しきれない状態になっていました。上記に伴う変更による影響範囲がわからない。また、エンジニアの増加に伴ってチームも増えていくため、チームの責任範囲を明確にしていく必要が
🎧 Railsのモジュラモノリス化とNext.jsの分割を実行中 #notetechtalk｜noteエンジニアチームの技術記事
noteのサーバサイドとフロントエンドのリアーキテクチャについて サーバサイドはPackwerkを利用してモジュラモノリス化 フロントエンドはNext.jsによるリアーキテクチャ それぞれの実施理由や進捗具合 ▼Podcastをもっと聴く
【初心者向け】gRPCを知るならここから！protobufバージョン別まとめ - asoview! Tech Blog
アソビュー株式会社でバックエンドエンジニアをしている進藤です。今回は、私がアソビューにジョインしてから初めて開発に使用するようになったRPCフレームワーク”gRPC”の要素技術のひとつであり、データフォーマットとシリアライズを行うためのツールProtocol Buffers（以降、protobufと表記）のおおまかな歴史とバージョン変遷について、ふりかえりの目的も兼ねて執筆してみようと思います。 私自身、前職での経験としていくつかのAPI開発に携わったことはありましたが、エンドポイントごとにクライアントコードを手動で記述し管理する煩雑さや、ビジネスサイドの要請により変化していくシステムの中でAPIの互換性を保つ難易度の高さに苦手意識を感じていました。 それがprotobufでは、複数の言語に対応したクライアントとサーバーのコードを自動生成することで異なるプログラミング言語間での通信が容易で
2023 JSConf JP 資料まとめ
はじめに JSConf JPに参加してきました。 後で見返せるように資料をまとめておきます。 Youtube Track A: https://www.youtube.com/watch?v=yxMJaXke9Hc Track B: https://www.youtube.com/watch?v=N1lhkH33fwY Track C: https://www.youtube.com/watch?v=pdgB0Y5ZQGk- Track D: https://www.youtube.com/watch?v=rDfPXDEot_A 資料リンク There and Back Again: A Proposal's Tale Web Internals: Mastering the JavaScript Engine Deep dive into Biome LLM全盛時代の開発プラクティス M
Railsでサービスを開発 / 運用をしていると、コードの肥大化に伴うモノリシック化に悩まされることも多いはず。2014年のサービス開始からRailsで進めてきたnoteも今まさにその壁に立ち向かっている最中です。 Railsアプリケーションを分割しようと考えたときに、マイクロサービス化や別言語でのフルリプレイスなどを検討することもあるはずです。 様々な選択肢がある中で、弊社ではPackwerkの導入とRailsエンジン化による分割を進めることにしました。（※ packwerk：Shopifyが作成したgem。依存関係をパッケージによって整理することができる） Railsエンジンを採用した大きな理由としては以下が挙げられます。 すばやく小さく問題を切り分けることを優先 マイクロサービス化はアーキテクチャから考慮する必要があり時間がかかる 将来的なマイクロサービス化の下準備として進めることが
「【ハイブリッド開催】Rubyで追求するモジュラモノリスの可能性」は、バックエンドにRubyを採用している株式会社タイミー、hacomono社、ワンキャリア社が、Rubyにおけるモジュラモノリスの可能性や良い点、悪い点を共有する勉強会です。ここで株式会社ワンキャリアの田中氏が登壇。まずは、ワンキャリアの開発が抱えている課題と、それに対して今までどういうことを試してきたかについて話します。 田中氏の自己紹介 田中晋太朗氏：はじめまして、ワンキャリアの田中です。私からは「モジュラモノリス構想」と題して、我々ワンキャリアが抱えている課題感であったり、これまでに試してきたこと、それからこれから試していこうと思っていること、構想の話をしていきます。 本題に入る前に軽く自己紹介させてください。株式会社ワンキャリア・CTOの田中と申します。過去、テック系のスタートアップを起業したり売却したりとかという経
アソビューを支える3つのSRE。それぞれの専門性を活かすための組織体制 - asoview! Tech Blog
アソビューでVPoTをしているdisc99🐼です！ 今回は、弊社のSRE(Site Reliability Engineering)と、その役割を果たすSREs(Site Reliability Engineers)について紹介させて頂きます！ アソビューのSREsが向き合う課題 弊社は現在、複数のサービスを提供しており、これらのサービスは規模としても大きく成長しています。 サービス全体像 システム規模 これらの状況の中で向き合う課題も複雑化してきており、代表的なものを上げると以下のようなものがあります。 多数のサービスと複数チームの意思決定を支えるSLO、SLI構築のリード 一秒間に数千リクエストを処理するためのスケーラビリティの向上 年々成長し続けるサービス、増え続ける会員/施設、拡張していくシステムの可用性の強化 人気商品発売やセールなど偏るトラフィックに対するノイジーネイバー問題
【イベントレポート】「ZOZO物流システムリプレイスの旅〜序章〜これまでとこれから」を開催しました！ - ZOZO TECH BLOG
はじめに こんにちは。DevRelブロックの@wirohaです。6月25日に「ZOZO物流システムリプレイスの旅〜序章〜これまでとこれから」を開催しました。ZOZOのエンジニアが物流システムリプレイス開発事例を紹介するイベントです。 登壇内容まとめ 弊社から次の3名が登壇しました。各発表はYouTubeにアップロードしてありますので、見逃した方やもう一度見たい方はぜひご覧ください。 コンテンツ 登壇者 分散メッセージングシステムを用いた新発送サービスのアーキテクチャ 作田 航平 ここがつらいよ 物流マイクロサービス 真田 洋輝 リプレイスを安心安全に 〜段階的リプレイスと等価比較〜 上原 駿 分散メッセージングシステムを用いた新発送サービスのアーキテクチャ www.youtube.com speakerdeck.com 作田からは発送サービスのアーキテクチャについて、リプレイス前後の比較や
Zennで会社テックブログを運用した振り返り
はじめに CEOの与謝です。Publication機能がリリースされて以降、弊社のテックブログはZennを使って運用しています。テックブログ始めました系の記事をあげる完全にタイミングを逃したので、ここで振り返りの意味も込めて書こうと思います。「テックブログ始めました」系の記事は多いですが、振り返り系は調べる限り少なかったので、よかったら参考にしてください。 運用ルール 厳格なルールは設けていませんが、普段開発も同時に進めている中で良コスパかつ品質を優先し、以下のことを意識して技術記事を上げるようにしています。 投稿のペースを設けない。 まとまったタスクが完了後、担当者が社外に共有できそうな知見を共有する。 テックブログを運用するにあたって、会社としてのモチベーションは 技術プレゼンスの向上 / エンジニア採用 を最終的な目標としていますが、担当者が技術記事でそれを達成することは難しいので、
実は 学校課題の要件を見間違えており、使用するバックエンドが Django ではなく Flask だったため書き直しました😇😇😇😇😇 Django版はこちら はじめに みなさん、マイクロサービスに疲れていませんか？ バックエンドにFlask, Laravelをたてているのに、フロントエンドで別途Next.js(Node.js)をたてているのが意味わからん モダンにWebサービスをたてたいだけなのに、なぜAPIを解放しないといけないのか [Flask React アプリ構築] [検索] 単純にバックエンドはFlask, フロントエンドにReactを使いたい、それだけなのに、こんな複雑な構成にしないといけないの...？ 今回ご紹介するモジュラモノリスなアーキテクチャでは、以下のようにサクッとWebサービスを構築できます。 from flask import Flask from fl
開発の歴史弊社のサービスローンチ期である 2016 年前後は「マイクロサービスアーキテクチャ」がトレンド化しており、海外では Netflix が大きな成果をあげたことで有名ですが、国内でもメルカリ等 多くの採用事例が続き話題となっていきました。弊社もマイクロサービスを採用し、当時においては比較的先駆者として様々なプラクティスを導入してきました。 開発チームの拡大に伴い、それぞれ開発のしやすさやデプロイ速度を優先し機能や案件に応じて サブスクリプション機能を管理するサービス、チャット機能を管理するサービス、健康プログラムを提供するサービスといったようにサービスはどんどん増えていきます。 気づけば、大小あれどサービス数は 60 以上に.. 結果としてそれに詳しい人が不在になる多くの「無人化サービス」が発生することになりました。 いわゆるマイクロサービスのメリットとして挙げられる「開発規模を小さ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
今後のスキルセットには必ず「AIを使いこなす」が組み込まれる GitHub CopilotとChatGPTの登場から考え直す、AIとの関わり方
マイクロサービス間通信における認証認可およびアクセス制御
身近なBtoCサービスを支えるアーキテクチャ大解剖 技術選定のポイントと今後の展望 - Findy Tools
『設計ナイト2024』に行ってきたよメモ - コード日進月歩
Node.jsで作るモジュラモノリスの設計と技術選定
チームの機能と配備を考えるための7つのチーム責務定義ガイドライン - mtx2s’s blog
JSConf JP 2023 公開資料・Xアカウントリンクまとめ
メンバーシップAppの開発とDDDの実践から得た学び - BASEプロダクトチームブログ
Railsでモジュラモノリスを実現する3つの代表的パターン 5つの基準で見たそれぞれの評価
入社して感じたBASEのいいなと思うところ - BASEプロダクトチームブログ
技術的な雑談をするテックトークを開催して半年が経ちました - Timee Product Team Blog
成長途中のサービスでモジュラモノリスを選択した2つの理由 人が増えてチームが分断されても生産性を維持するために
「横に割ってダメなら縦に割りましょう」 データベースの“大きな泥だんご“状態解消に向けた垂直分割
食べログエンジニア組織2023年振り返り - Tabelog Tech Blog
越境が簡単なRailsでどのようにモジュラモノリスを実現するか 「境界分け」と「Active Recordの制限」に対する取り組み
RubyKaigi 2024に参加できて本当に良かった - joker1007’s diary
STORES 予約 をモジュラモノリス化しました！ - STORES Product Blog
Ubieにおけるプラットフォームエンジニアリングの取り組み2023 - 電気ひつじ牧場
シード期からモジュラモノリスに手を出したスタートアップの末路
Kotlin製のGraphQLサーバーをNode.jsでモジュラモノリス化している話
拡大期のサービスのモジュラモノリス移行を考えたらチーム編成の難しさにぶつかりそうな話
タイミーはどのようにしてモジュラモノリス化を進めたか packwerkの導入と、悩んだ2つのポイント
RailsエンジンとPackwerkによるコード分割を進行中｜noteエンジニアチームの技術記事
変更影響に恐怖しながら扱っていたデータベース “大きな泥だんご”状態を解消するために水平分割やってみた
Flask + Inertia + Vite + React で作る Web アプリの新たな選択肢
モジュラーモノリスへ ~過剰なマイクロサービスの統廃合に取り組み始めた話~