エムスリーのデータ基盤を支える設計パターン - エムスリーテックブログ
こんにちは、エムスリー エンジニアリンググループ の鳥山 (@to_lz1)です。 ソフトウェアエンジニアとして 製薬企業向けプラットフォームチーム / 電子カルテチーム を兼任しています。 ソフトウェアエンジニアという肩書きではありますが、私は製薬企業向けプラットフォームチームで長らくデータ基盤の整備・改善といったいわゆる "データエンジニア" が行う業務にも取り組んできました。 本日はその設計時に考えていること / 考えてきたことをデータ基盤の設計パターンという形でご紹介しようかと思います。多くの企業で必要性が認識されるようになって久しい "データ基盤" ですが、まだまだ確立された知見の少ない領域かと思います。少しでもデータエンジニアリングを行う方の業務の参考になれば幸いです。 データ基盤の全体像 収集部分の構成 RDBデータ ログデータ 活用部分の構成 データマートの実例 「データ基
オブジェクト指向の複雑性を軽減する、データ指向プログラミング入門
思った以上に反響をいただき嬉しく思っています。SNSやコメントで言及していただいている構造化プログラミングとの比較や現代的なOOP開発への適応記事を執筆予定です。記事が完成しましたら自分のSNSで共有いたしますので、もし良ければフォローしてお待ちいただけますと幸いです。（記事を書くのは思考が整理されて良いものですね。） TL;DR データ指向プログラミング(DOP) とは、データとコードを分割してアプリケーションを設計・実装するプログラミングパラダイムのこと。 DOPの実装は、以下の原則に従う。 コードとデータを分離する 汎用的なデータ構造でデータを表現する データをイミュータブルなものとして扱う データスキーマとデータ表現を分離する 個人的にDOPは、バックエンドを宣言的プログラミングっぽく書くための現実的な解だと捉えています。実装の詳細は翔泳社より出版されている「データ指向プログラミン
GitHub - ByteByteGoHq/system-design-101: Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.
Architecture styles define how different components of an application programming interface (API) interact with one another. As a result, they ensure efficiency, reliability, and ease of integration with other systems by providing a standard approach to designing and building APIs. Here are the most used styles: SOAP: Mature, comprehensive, XML-based Best for enterprise applications RESTful: Popul
AWSでの法令に則ったログ設計及び実装/分析 - Adwaysエンジニアブログ
エージェンシー事業でリードアプリケーションエンジニアを行なっている大窄 直樹 (おおさこ)です. AWSのログ, サーバーのログってたくさん種類があって難しいですよね... 同じようなログがたくさんあるので, 何を取れば良いのかとか どのくらいの期間保持すれば良いのかとか またその後の, ログの実装や, 分析方法する方法も難しいですよね... 今回AWSに構築した商用アプリケーションのログを整備する機会があったので, このことについて書こうかなと思います. 概要 本題に入る前の準備 今回ログ実装するアーキテクチャ ログに関する法令 ログの取得箇所 設計 保管するログの決定 インフラのログ OSのログ アプリケーションのログ ログの保管 保管場所について 保管期間について バケット構造 アプリケーション, OSのログの転送 実装 アプリケーション, OSのログをfluentbitを用いてS3
いまNext.jsで新規サービスを立ち上げるときの観点（Router・CSS・認証・監視など/2023年末）
免責事項 社内向けに展開するように雑にまとめました Next.jsの知見が深くない人がリードしてPoCを立ち上げなきゃいけなくなったが、社内的にはNext.jsを推奨しているみたいな場面を想定しています なので自信ないところも多いですが割と断言するように心がけて書いています PoCの立ち上げ想定なので、jest/Storybookなど内部品質面についてあまり深く書くことを避けています ほぼ自分の知識だけで書いており私見も多いですし、そもそも自分自身がトップクラスの知識や視座を有しているわけでもないので、まずは以下の話を理解はした上で、踏襲するかどうかは別途他記事やGitHub、公式ドキュメントなどを漁って判断することを推奨 App RouterかPages Routerか 2023年末現在まだApp Routerは技術記事が足りてきている印象ではないため、社内でノウハウを積極的に貯めていく
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
GraphQLはいつ使うか、RESTとの比較
さぼです、沖縄でWebと設計について考えてます。2023/09/23 に沖縄で行われたTechBaseOkinawa2023 にて上記のタイトルで登壇しました。 今回の内容は GraphQLを設計の観点から考えてみる GraphQLの目的や用途を整理する GraphQLを使う時、または使わない時のヒントを持ち帰ってもらう 最近、GraphQLじゃなくてRESTで良くないと思うケースがなんとなくわかってきたのでそれを共有する という感じで話しました。話した内容を文字に起こし少し改修してZennでも共有することとします。 まえおき 最近はクライアントAppとサーバーAppを分けて実装する事が増えてきた クライアントの環境はますます複雑になっている クライアントとサーバーはWebAPIで通信を行う クライアントが複雑になるのと同時にWebAPIの要求が更に増して来ている APIの要求・応答を効率
設計・ソフトウェアアーキテクチャを学べるGitHubリポジトリ 16選
はじめに 今回の記事では、設計やソフトウェアアーキテクチャを学べるGitHubリポジトリを16個紹介する。 対象とする読者 設計やソフトウェアアーキテクチャに興味関心があるエンジニア GitHubをエンジニアリングの情報収集に活用したいエンジニア タイトルで気になった人 Architectural Patterns システムの基本的な構成を理解するためのパターンやテンプレートを提供している。これらのパターンを学ぶことで、システムの構造やコンポーネントの関連性、相互作用を理解できる。これが開発者にシステムをより効率的かつ効果的に設計・実装する能力をもたらす。 Design Patterns for Humans 設計パターンを人間が理解しやすい形で説明している。デザインパターンは特定の問題に対して再利用可能なソリューションを提供する。これによって、開発者はより効率的にコードを記述でき、メンテ
ソシャゲサーバー開発するとき始めに考慮しておかないと死ぬポイント備忘録
事前知識編 システム開発するプログラマも読んでおいたほうがいい資料とか。 今時のシステムならまず仕様や運用に反映される。されてなかったらむしろこっちから確認取りに行った方がいい。 JOGAガイドライン 昔ガチャとかが問題になったときに出てきた協会のガイドライン。 オンラインゲーム安心安全宣言 オンラインゲームにおけるビジネスモデルの企画設計および運用ガイドライン ランダム型アイテム提供方式を利用したアイテム販売における表示および運営ガイドライン オンラインゲームガイドライン 開発環境編 GitHubみたいなPullRequestを出せる環境 GitだけじゃなくてGitHub。必然的に規模が大きくなるのでプルリク出して進めることになります。 CIまで設定をする 最初のうちにCircleCIのようなテストの自動実行する仕組みまで揃えてしまっておいたほうが良いです。後からだとそもそも対応できなく
サブスクリプション課金システム開発ケーススタディ - inSmartBank
世はまさに大サブスクリプション時代。この潮流の中で弊社スマートバンクもまた、去る2023年7月12日にB/43プラスというサブスクリプションサービスをリリースしました。 サブスクリプションといえばユーザーに提供されるコンテンツや機能といった直接的な価値に焦点が当たりがちですが、その土台にはサブスクリプションビジネスを成立させるための課金システムがあります。本記事では筆者が行った課金関連の開発を振り返ってみて重要だったポイントや工夫点を伝えてみたいと思います。 すでに世に多くのサブスクリプションサービスがある中で、課金システムの実装はコモディティ化した単純な作業に思えるかもしれません。しかしながら自社サービスにてゼロから実現するとなると、想像よりも多くの思考と意思決定が必要とされる、エンジニアリング観点ではとても奥深い題材といえます。いち開発プロジェクトのケーススタディ、あるいはいちプログラ
Data Developer Platform
Home Data Developer Platform¶ A Data Platform Specification, open for adoption by any data platform developer. A modern way to run data engineering teams¶ Data teams are drained from continuously plumbing integrations and fragile pipelines, which leaves little to no time to focus on the real deal - data and data applications. Businesses that have a good grasp on data realise that today data makes
今さら聞けないログの基本と設計指針 - Qiita
はじめに 皆さんのログに対する理解はどんなものでしょうか？仕組みから設計方法まで完璧に理解しているエンジニアもいれば、なんとなく使用しているエンジニアも多いことでしょう。 ログとは、システムに着いてエラーや障害の発生、利用者による操作や設定の変更、外部との通信などを時系列に記録したものです。ログに関する理解を深めることで、複雑なシステム開発や運用が可能となります。また、AWS、Azure、GCPなどのクラウドサービスを利用している場合はシステムの開発が可能になるだけでなく、経費削減に繋がる可能性も考えられます。 本記事では、ログの基本を押さえるためにその設計方法について解説します。少しでも自信がない方は、ご一読ください。 ログを出力する理由は？ ログの基本や、ログの設計について解説する前にそもそもログを出力する理由を押さえましょう。大きく4つの理由が考えられます。 ・問題が発生した時に調査
同時接続数30万超のチャットサービスのメッセージ配信基盤をRedis Pub/SubからRedis Streamsにした話
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog Overview 30万を超える同時接続数を持つチャットサービスにおいて、リアルタイムでメッセージの受信などのイベントを配信するメッセージブローカーとして、私たちはRedis ClusterのPub/Subを使用していました。 私たちのサービスでは、ユーザー数の増加に伴い、Redis Clusterのシャード数を増やすことでクラスターの性能を向上させてきました。しかし、Redis ClusterのPub/Subでは、シャード数の増加に伴ってネットワーク帯域が圧迫される問題が生じ、これ以上シャードを追加することができない状況になりました。 この課題を解決するために、メッセージブローカーをRedis Pub/SubからRedis
Amazon MSKを用いてMySQLに対してChange Data Captureを実現する - ZOZO TECH BLOG
はじめに こんにちは。基幹システム本部・物流開発部の作田です。現在、ZOZO社内で使用している基幹システムのリプレイスを担当しています。 現在行っているリプレイスでは、既存の基幹システムから発送機能を切り出し、マイクロサービスに移行しています。リプレイスの詳細については、ZOZOBASEを支える発送システムリプレイスの取り組みをご覧ください。 techblog.zozo.com マイクロサービスは発送業務の各作業が完了したことを基幹システムに連携しており、この連携を実現するためにAmazon Managed Streaming for Apache Kafka（以降、Amazon MSK）を採用しました。今回は、サービス間のデータ連携にAmazon MSKを採用した理由やAmazon MSKでの実装例と考慮点について紹介します。MySQLなどのリレーショナルデータベースに対してAmazon
新規作成画面をなくすと考慮事項が激減して嬉しい
例えば CMS の管理画面を考えます。 /posts に記事一覧画面、/posts/new に新規作成画面、 /posts/:postId に記事更新画面を置くような URL の設計はあるあるかと思います。 今回は /posts/new の画面はないほうが色々嬉しいと思った話をします。 新規作成画面があることで増える考慮事項 まず新規作成画面があると、どんな煩わしさがあるかを考えます。 下書き保存した時、どうする？ 新規作成画面で下書き保存をすると、内部的にはリソースの ID が採番されます。つまり下書き保存した段階で、それは記事更新画面になるはず。 その ID で URL を /posts/:postId に書き換えるかどうかを検討します。 筆者は React 一辺倒人間なので React 寄りの話にはなりますが、Next.js や React Router などでは /posts/ne
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Flutter設計パターン入門
ジョインしたチームのマイクロサービスたちを再計装した話 / Getting started tracing instrument micro service with OpenTelemetry
Scrapboxの哲学 - 橋本商会
https://www.amazon.co.jp/%E3%81%AA%E3%81%9C%E9%87%8D%E5%A4%A7%E3%81%AA%E5%95%8F%E9%A1%8C%E3%82%92%E8%A6%8B%E9%80%83%E3%81%99%E3%81%AE%E3%81%8B%EF%BC%9F%E9%96%93%E9%81%95%E3%81%84%E3%81%A0%E3%82%89%E3%81%91%E3%81%AE%E8%A8%AD%E8%A8%88%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E6%94%B9%E8%A8%82%E7%89%88%EF%BC%88%E6%97%A5%E7%B5%8CBP-Next-ICT%E9%81%B8%E6%9B%B8%EF%BC%89-%E6%A3%AE%E5%B4%8E%E4%BF%AE%E5%8F%B8-ebook/dp/B01683BFJM
Goで実装された高速な
仮想待合室サーバの実装と詳解
