並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 231件

新着順 人気順

bigtableの検索結果1 - 40 件 / 231件

  • クリーンアーキテクチャ完全に理解した

    clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心

      クリーンアーキテクチャ完全に理解した
    • 2020年現在のNewSQLについて - Qiita

      Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海

        2020年現在のNewSQLについて - Qiita
      • Elasticsearch運用ノウハウ | メルカリエンジニアリング

        こんにちは、メルカリMicroservices SREチームの藤本(@jimo1001)です。 私は現在、Embedded SRE として サーチインフラチームに入り活動しています。このサーチインフラチームは、Elasticsearchを使用した検索基盤を管理し、様々なマイクロサービスに検索機能を提供するチームです。この検索基盤は非常に巨大なプラットフォームで、メルカリ全体のマシンリソースの高い割合を占めており、メルカリの検索を支える非常に重要なものです。私の Embedded SRE としてのミッションは検索基盤の信頼性の向上と自動化を推進することです。 今回は、メルカリの検索基盤で利用している Elasticsearch における運用のノウハウを紹介したいと思います。 Elasticsearch とは Elasticsearch は、Elastic社が開発する Apache Lucen

          Elasticsearch運用ノウハウ | メルカリエンジニアリング
        • NoSQLデータモデリング技法 · GitHub

          NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文:NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック

            NoSQLデータモデリング技法 · GitHub
          • 1000万ユーザに耐えるサーバを作ってみた

            概要 スケーラビリティが高く1000万ユーザに耐えるAPIサーバを作成しました。TwitterのようなSNSです。実装はGitHubで公開しています。 開発環境は次の通りです。 Node 16.14 Express 4.17.3 DynamoDB 2012-08-10 機能要件は次の通りです。 ツイート機能 ツイートに対してコメント機能 フォロー機能 タイムライン機能 導入 Facebook、Amazon、Youtubeのような数億人のユーザを抱えるサービスでは大量のトラフィックを捌く必要があります。大量のトラフィックを捌くためのアプローチとして一般的に使われるのはスケールアップではなくスケールアウトです。スケールアップは性能の高い機器を使うためにコストが高いです。また、1つのサーバで運用するためにパフォーマンスの限界が存在します。 スケールアウトについて考えます。アプリケーションは大きく

              1000万ユーザに耐えるサーバを作ってみた
            • Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -その1- - inductor's blog

              このエントリーについて このエントリーを書き始めた経緯は下記にあります。 inductor.hatenablog.com 上記の理由の通り、目的は論文を翻訳することだけではなく、最終的にこれを踏まえて自分の見解をつらつらと書いていくところにもあります。 おそらく一番時間がかかるのはそれなので、一旦は翻訳を一通り終えた上で更に頑張っていきます。ゆっくりお待ちいただければと思います>< 1. Introduction(まえがき) Borgが内部的に呼び出すクラスター管理システムは、Googleが実行するすべてのアプリケーションを許可、スケジュール、起動、再起動、および監視します。この論文ではその方法を説明します。 Borgには3つの主な利点があります。 リソース管理と障害処理の詳細を隠すため、ユーザーは代わりにアプリケーション開発に集中できます。 非常に高い信頼性と可用性で動作し、同じことを行

                Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -その1- - inductor's blog
              • 2020年やったこと、考えたこと、触った技術のまとめ - mizchi's blog

                今年の本業は、 3rd party script で、そこから呼ぶウィジェットを最適化するコンパイラを書く、その仕様を考えて、実装するという感じだった。要は Google Analytics と、最適化コンパイラ付き GTM みたいなものを作っていた。その内容は以下に書いた。 サードパーティスクリプトの極限環境向け Svelte パフォーマンス改善に Core WebVitals という大義名分を得た 今年は、 パフォーマンスのエンジニアをやっていた、と思う。サードパーティスクリプトの配信を生業にする会社のエンジニアとしては、来年の Core WebVitals というパフォーマンス関連の大きな変化で、波にのってやりたいことがやれたと思う。 Core WebVitals の導入で実際にどれぐらいの影響がでるか不明だが、パフォーマンスが SEO に影響する、というのは、 若干やりすぎと思いつ

                  2020年やったこと、考えたこと、触った技術のまとめ - mizchi's blog
                • データ分析基盤まとめ(随時更新)

                  はじめに データ分析基盤の資料を力尽きるまで追記していきます。 構成図にあるアイコンや記事の内容から技術要素を調べて記載していますが、不明分は未記載にしています。修正のコメント頂ければ助かります。 あと、この記事追加してっていう要望も歓迎いたします。 テンプレート 記事公開日 : 会社名(サービス名) データソース : データ処理 : アウトプット : 画像 URL 2025年 2024/03/14 : 株式会社エス・エム・エス(カイポケ) データソース : Amazon Aurora データ処理 : Datastream、BigQuery、dbt アウトプット : Looker Studio 2024/03/12 : 株式会社マイナビ データソース : SQL Server、Amazon S3 データ処理 : Embulk、Amazon MWAA、Apache Airflow、Snowf

                    データ分析基盤まとめ(随時更新)
                  • マイクロサービスにクリーンアーキテクチャを採用する上で考えたこと | メルカリエンジニアリング

                    Merpay Advent Calendar 2019 の19日目は、Backendエンジニアチームの @toshinao がお送りします。 新しくマイクロサービスを立ち上げる機会があり、クリーンアーキテクチャをベースにしました。クリーンアーキテクチャはバックエンド・フロントエンド・アプリなど様々な場所で採用されています。ただ、確固たる方法というのは無く、みな試行錯誤しているのでは無いでしょうか。この記事では、クリーンアーキテクチャを取り入れる上で考えたことを紹介したいと思います。 マイクロサービスを作ったことがない人や、今までいくつか作ってきたけどより良い設計について考えている人の助けになれば幸いです。 はじめに メルペイのバックエンドは主にGoとGoogle Cloud Platform(GCP)で開発を行っていますが、各マイクロサービスをどう実装していくかは概ね各チームに委ねられてい

                      マイクロサービスにクリーンアーキテクチャを採用する上で考えたこと | メルカリエンジニアリング
                    • Pokémon GO が数百万ものリクエストへの対応を実現している方法 | Google Cloud 公式ブログ

                      ※この投稿は米国時間 2021 年 10 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。 ポケモンを捕まえたことはありますか?Pokémon GO は何百万人もの人がプレイする人気ゲームですが、非常に優れたスケーラビリティを実現しています。このブログでは、Pokémon GO のエンジニアリング チームがどのようにこの大規模なサービスを管理し、維持しているのか、その舞台裏を紹介しています。Niantic Labs のシニア エンジニアリング マネージャーで、  Pokémon GO のサーバー インフラストラクチャ チームを率いる James Prompanya 氏に、この大人気ゲームを支える  アーキテクチャについてお話を伺いました。動画をご覧ください。 Priyanka: Pokémon GO とは? James:  これは典型的なモバイルゲームではあ

                        Pokémon GO が数百万ものリクエストへの対応を実現している方法 | Google Cloud 公式ブログ
                      • 20年でソフトウェア開発の景色はどのぐらい変わったのか? - Qiita

                        PySpa統合思念体です。 某チャットで、「今時のOSSのプロジェクト管理とかのベストプラクティスが書いてある本ないかな、陳腐化早そうだしないか」みたいな話題が投入されました。その中で、エキスパートPythonプログラミングとか、Pythonプロフェッショナルプログラミングとかは思い出して紹介したけど、他の人からはShip It、Manage It、Release It三部作とか、達人プログラマーとかも出てきました。 このあたりの源流を辿ると、そういえば今流行ってる開発の源流としてはエクストリームプログラミングの開発系のプラクティスの遺伝子を受け継いでいるのが多いよな、そういえば当時から見て今ってどう変わっているのかな、という話題に。せっかくなので20年前を思い出しつつ、当時と今でどういう風に変わってきたのか適当にまとめてみます。 20年前の状況 XP白本こと、eXtreme Progra

                          20年でソフトウェア開発の景色はどのぐらい変わったのか? - Qiita
                        • 分散データシステム入門の決定版『データ指向アプリケーションデザイン』をたった30分で学んでみた #DataEngineeringStudy | DevelopersIO

                          基調講演「30分でわかるデータ指向アプリケーションデザイン」 ・ スピーカー 斉藤 太郎氏  Twitter:@taroleo / Github:@xerial Principal Software Engineer , Treasure Data 東京大学理学部情報科学科卒。情報理工学 Ph.D。データベース、大規模ゲノムデータ処理の研究に従事。その後、スタートアップであるTreasure Dataに加わり、アメリカ、シリコンバレーを拠点に活動中。日本データベース学会上林奨励賞受賞。OSSを中心にプログラミングやデータ処理を簡単にするためのプロダクトを作成している。 「30分でわかるデータ指向アプリケーションデザイン」最新の論文にも触れながら、分散データシステムの世界の魅力を伝えていきます。後半、@tagomoris https://t.co/TQ2TnsFIOT… — Taro L.

                            分散データシステム入門の決定版『データ指向アプリケーションデザイン』をたった30分で学んでみた #DataEngineeringStudy | DevelopersIO
                          • Googleに入社して10年が経ちました - YAMAGUCHI::weblog

                            はじめに こんにちは、Cloud Operations suite担当者です。2021年4月18日でちょうどGoogleに入社して10年が経ちました。自分は転職で入社したときのことは書いておらず、前職を退職したときの記録しか残っていませんでした。いい機会なので記録として10年間を振り返ってみようかなと思いました。自分用の振り返りで特に推敲もしておらず、読みづらいと思いますが、とりあえずそのまま出します。 Google入社のきっかけ 当時はPython関係のコミュニティ活動やアウトプットをしていて、ちょうどそのときにGoogleのPartner Solution Organization(いまの gTech という組織の前身)のTechnical Account Managerという職種で空きがあるので、受けてみませんかとメールが来たのがきっかけでした。当時はGoogleというとソフトウェア

                              Googleに入社して10年が経ちました - YAMAGUCHI::weblog
                            • Railsで秒間1000コミットを捌くにはどうすればいいのか (Kaigi on Railsのフリースペースより) - joker1007’s diary

                              先日のKaigi on Rails中の雑談として @ima1zumi さんから、RDBに対して秒間1000コミットぐらいで処理が詰まってる場合ってどうするのが良いのか、という質問を受けまして、雑談の中で色々答えてたんですが、せっかくだから記事にまとめておこうと思います。 ちょっとしたKaigi Effectって感じですね。 今回のKaigi on Railsのトークの中では、 数十億のレコードを持つ5年目サービスの設計と障害解決 by KNR - Kaigi on Rails 2023 の話なんかは割と関連がありますね。ユーザーの行動履歴というのは、ユーザー数 * N * タイムスパンで増えていくレコードなので、書き込みとデータ量が爆発しがちです。トランザクションで堅牢に処理しなければいけないケースもそこまで多くないので、RDBだと書き込みに対する処理が過剰なケースが多い。実際のところこの

                                Railsで秒間1000コミットを捌くにはどうすればいいのか (Kaigi on Railsのフリースペースより) - joker1007’s diary
                              • RDBの限界とNoSQLの登場

                                事実世界のインターネット人口が増えたのは1990年代からだ。 [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h29/html/nc144210.html __NoSQL__の登場 1990年に入るとインターネットの利用人口が急激に増加することになる。 この頃からトランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。 多くの開発者は、単一の強力なサーバーでリレーショナル・データベースを実行するのではなく、リレーショナル・データベース管理システム (RDBMS) のパーティショニング (シャー

                                  RDBの限界とNoSQLの登場
                                • なぜリモートでも完全にペアプロで開発するのか? XPのプラクティスをどこまでも徹底するユーザベースの挑戦を恐れない開発文化 - はてなニュース

                                  ステイホーム期間が続き、開発者がオフィスで顔を突き合わせることも少なくなっています。そんなリモートワークが既定となった状況下でも、ユーザベースのB2B SaaS事業では開発に関わる全てを徹底してペアプログラミングで行っています。 その根幹には、XP(eXtreme Programming)のプロセスを推進することで開発効率を向上させる意図があり、それが多種多様なプログラミング言語やマイクロフロントエンドといった目新しい技術を恐れることなく積極的に採用する開発文化を生み、ひいてはシェアドリーダーシップによる自己組織化されたチームのあり方につながっています。 わずか10人程度だったエンジニア組織を4年で10倍の規模に拡大し、さらに組織と事業の成長を目指すCTOの林尚之さん、スペシャリストとしてFellowの肩書を持つ板倉大輔さん、入社2年目のエンジニア片山景太さんの3人にお話をうかがいました。

                                    なぜリモートでも完全にペアプロで開発するのか? XPのプラクティスをどこまでも徹底するユーザベースの挑戦を恐れない開発文化 - はてなニュース
                                  • 話題の AlloyDB は本当に凄いデータベースなのでプレビューを使い倒した #devio2022 | DevelopersIO

                                    ウィスキー、シガー、パイプをこよなく愛する大栗です。 この度クラスメソッド株式会社で開催している技術イベント DevelopersIO 2022 のアーカイブ動画セッションに登壇しましたので、ブログで解説を行いたいと思います。なお本内容は2022年6月時点の内容となっていますので、現在の状況とは異なっている場合がございますのでご了承ください。 AlloyDB for PostgreSQL は2022年7月27日現在において、プレビューのステータスです。このプロダクトまたは機能は、Google Cloud Platform の利用規約の一般提供前のサービス規約の対象となります。一般提供前のプロダクトと機能では、サポートが制限されることがあります。また、一般提供前のプロダクトや機能に変更が加えられると、他の一般提供前バージョンと互換性がない場合があります。詳細については、リリースステージの説明

                                      話題の AlloyDB は本当に凄いデータベースなのでプレビューを使い倒した #devio2022 | DevelopersIO
                                    • 次世代データ基盤:データレイクハウスを Google Cloud で実現する

                                      はじめに こんにちは、クラウドエース データソリューション部の松本です。 普段はデータ基盤や MLOps の構築をしたり、Google Cloud 認定トレーナーとしてトレーニングを提供しております。また、昨年は Google Cloud Partner Top Engineer 2024 に選出されました。今年も Goodle Cloud 界隈を盛り上げていけるよう頑張っていきたいと思います。 クラウドエース データソリューション部 について クラウドエースのITエンジニアリングを担う システム開発統括部 の中で、特にデータ基盤構築・分析基盤構築からデータ分析までを含む一貫したデータ課題の解決を専門とするのが データソリューション部 です。 弊社では、新たに仲間に加わってくださる方を募集しています。もし、ご興味があれば エントリー をお待ちしております! 今回は、次世代データ基盤であるデ

                                        次世代データ基盤:データレイクハウスを Google Cloud で実現する
                                      • ZOZOTOWNを支えるリアルタイムデータ連携基盤 - ZOZO TECH BLOG

                                        こんにちは、SRE部MA基盤チームの谷口(case-k)です。私達のチームでは、データ連携基盤の開発・運用をしています。 データ基盤には大きく分けて2種類あり、日次でデータ連携してるものとリアルタイムにデータ連携しているものがあります。本記事ではリアルタイムデータ連携基盤についてご紹介します。 既存のデータ連携基盤の紹介 リアルタイムデータ連携基盤の紹介 なぜ必要なのか 活用事例の紹介 データ連携の仕組みと課題 リプレイス後のリアルタイムデータ連携基盤 SQL Serverの差分データの取り方を検討 アーキテクチャ概要と処理の流れ Fluentdのプラグインを使った差分データの取得 Dataflowでメッセージの重複を排除 Dataflowで動的にBigQueryの各テーブルに出力 Pub/Subのメッセージ管理 イベントログ収集基盤 個人情報の取り扱い ビルド・デプロイ戦略 監視 データ

                                          ZOZOTOWNを支えるリアルタイムデータ連携基盤 - ZOZO TECH BLOG
                                        • RDBの限界とNoSQLの登場 - Qiita

                                          事実世界のインターネット人口が増えたのは1990年代からだ。 [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h29/html/nc144210.html NoSQLの登場 1990年に入るとインターネットの利用人口が急激に増加することになる。 この頃からトランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。 多くの開発者は、単一の強力なサーバーでリレーショナル・データベースを実行するのではなく、リレーショナル・データベース管理システム (RDBMS) のパーティショニング (シャーディング

                                            RDBの限界とNoSQLの登場 - Qiita
                                          • モノリシックなアプリケーション開発から小さなアプリケーション開発へ(Software Design連載 2022年3月号:設計方針から変えていく、 モノリシックなアプリの過去と未来) - MonotaRO Tech Blog

                                            この記事の初出は、Software Design2022年3月号「設計方針から変えていく、モノリシックなアプリの過去と未来(最終回)」で、加筆修正されています。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか - MonotaRO Tech Blog 第2回 Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog 第3回 Software Design連載 2021年10月号 スナップショットテストの可能性を追求する - MonotaRO Tech Blog 第4回 Software Design連載 2021年11月号 Robot FrameworkでE2Eテストを自動化する - MonotaRO Te

                                              モノリシックなアプリケーション開発から小さなアプリケーション開発へ(Software Design連載 2022年3月号:設計方針から変えていく、 モノリシックなアプリの過去と未来) - MonotaRO Tech Blog
                                            • SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか【Backlog Play 化プロジェクト】 | Backlogブログ

                                              Backlog SREチームのmuziです。2018年4月から2019年7月まで、BacklogをJavaからScala / Play Frameworkに移行する大規模なリプレイスプロジェクトに参加していました。 SREとして、このリプレイスにはかなりの困難が伴いました。特にBacklogのサービス安定性は大きな問題でした。 本記事では、こうした問題に対して、SREである私がどういうアプローチを取ったのか、そしてこのプロジェクトで得られた教訓を今後チームや組織全体でどのように活かそうとしているかをご紹介します。 正直言って、泥臭い話だらけの内容です。それでも、技術的負債を抱えたプロジェクトでSREが取れるアプローチの事例の一つとして、読者の参考になれば幸いです。 はじめに ヌーラボでは2015年11月から2019年7月まで、BacklogをJavaからScala / Play Frame

                                                SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか【Backlog Play 化プロジェクト】 | Backlogブログ
                                              • NoSQLデータベースCassandraの紹介 〜 ヤフーのデータ基盤を支える技術

                                                ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは! 山下郁矢です。2018年新卒で入社し、現在はNoSQLデータベースエンジニアとして働いています。 サービスを作るにあたってデータベースは必要不可欠ですよね。ヤフーでは100を超えるサービスで毎日生み出される膨大なデータを、データベースを用いてリアルタイムで蓄積し、運用管理しています。 今回は、その中でも利用規模の大きい、NoSQLデータベースの1つであるApache Cassandraを皆様に知ってもらうべく、ヤフーでどのようにして利用されているのかをお伝えしたいと思います。 NoSQLの立ち位置 Cassandraについてご紹介する前に、NoSQLについて軽く説明します。 NoSQLデータベースは一般的に非RDBM

                                                  NoSQLデータベースCassandraの紹介 〜 ヤフーのデータ基盤を支える技術
                                                • Git と GitHub の次を妄想する

                                                  GitHub みたいなサービスを今一から作るならどの言語・フレームワークを使うか GitHub の次は何かを考えてみるのは、現実に実現困難なのを忘れれば、なかなかに楽しいことではあります。ここではその妄想をやっていきましょう。 GitHub の抱える課題を分割すると、Git の問題と、 GitHub の提供する機能の問題に分けられると思います。自分は、Git をベースとして GitHub に勝つのは現代ではなかなか難しいと考えています。MS による買収と実際に注ぎ込まれてる資本を考えると、よほど斬新な切り口でないと、 同じ Git を使っても優位性は出せません。 なので、 GitHub に本質的に勝つには、その基幹となる VCS から考え直すとよいのではないか、と考えています。幸いなことに(?)、Git はその優秀さは認められていますが、学習の困難さや特定のユースケースで機能しないことが知

                                                    Git と GitHub の次を妄想する
                                                  • bradfitz - Leaving Google

                                                    After ~12.5 years at Google and ~10 years working on Go (#golang), it's time for me to do something new. Tomorrow is my last day at Google. Working at Google and on Go has been a highlight of my career. Go really made programming fun for me again, and I've had fun helping make it. I want to thank Rob Pike for letting me work on Go full time (instead of just as a distraction on painfully long gBus

                                                    • How Pokémon GO scales to millions of requests? | Google Cloud Blog

                                                      Priyanka VergadiaStaff Developer Advocate, Google Cloud Have you caught Pokémons? Pokémon GO is a popular game played by millions, but it scales extremely well. This blog is a behind-the-scenes look into how the Pokémon GO engineering team manages and maintains the scale. Joining me is James Prompanya, Senior Engineering Manager at Niantic Labs who leads the server infrastructure team for  Pokémon

                                                        How Pokémon GO scales to millions of requests? | Google Cloud Blog
                                                      • SREってなんだ?哲学と習慣、そしてツール。

                                                        1.SREの哲学と原則 SREは”DevOpsを純粋な形にしたもの”なのか SRE担当VPとして、Matthew FlamingはNew RelicのSREプラクティスを監督しています。SREはおそらく”DevOpsの原則を単一の役割に最も純粋に蒸留したものだ”と彼は考えています。 昨年の FutureStack New YorkでGoogleのSREであるLiz Fong-Jones氏はこの考えを広げました。Googleのソフトウェアエンジニアは、運用システムのコードと信頼性に常に責任を負っていますが”SREはさまざまなシステムがどのように連携するか、どのように機能するか、そしてどのように改善されるべきかについて、専門的な理解を深めることに責任がある”と彼女は言いました。SREはソフトウェアエンジニアリングのタスクを引き受ける可能性がありますが、エンジニアリングチームが提供するサービスの

                                                          SREってなんだ?哲学と習慣、そしてツール。
                                                        • The History of Distributed Databases - Google, Amazon, Facebook など巨大企業による分散データベース技術の発展 | Wantedly Engineer Blog

                                                          こんにちは、Wantedly の Infrastructure Team で Engineer をしている南(@south37)です。 今日は、WANTEDLY TECH BOOK 5 から「巨大企業による分散データベース技術の発展」という章を抜粋して Blog にします。 「WANTEDLY TECH BOOK 1-7を一挙大公開」でも書いた通り、Wantedly では WANTEDLY TECH BOOK のうち最新版を除いた電子版を無料で配布する事にしました。Wantedly Engineer Blogでも過去記事の内容を順次公開予定であり、この Blog もその一環となっています。 Wantedly における Go 導入にまつわる技術背景 | Wantedly Engineer Blog (本記事は Go Conference 2019 Autumn にて無料配布した冊子『WANT

                                                            The History of Distributed Databases - Google, Amazon, Facebook など巨大企業による分散データベース技術の発展 | Wantedly Engineer Blog
                                                          • クラウドネイティブ アーキテクチャ、5 つの原則 | Google Cloud 公式ブログ

                                                            ※この投稿は米国時間 2019 年 6 月 20 日に Google Cloud blog に投稿されたものの抄訳です。 私たち Google Cloud は、Google Cloud Platform(GCP)上に移行もしくは構築されるアプリケーションの最終目標として、よく「クラウドネイティブ アーキテクチャ」という言葉を使います。では、クラウドネイティブとは正確にはどういう意味なのでしょうか。そして、そのようなシステムはどうすれば設計できるのでしょうか。 大まかに言えば、クラウドネイティブとは、クラウドによってもたらされる、従来のオンプレミスにはない新しい可能性に適応することを意味します(アーキテクチャ上の制約も従来とは大きく異なるため、それにも適応)。ソフトウェア アーキテクトとして私たちが考慮するよう訓練を受けている高レベルの要素について考えてみましょう。 システムの機能要素(何を

                                                              クラウドネイティブ アーキテクチャ、5 つの原則 | Google Cloud 公式ブログ
                                                            • 【保存版】Azure/AWS/Google Cloud(GCP)/OCI サービス比較 - NOBTAの気ままにITブログ

                                                              ※ 2021年1月 更新 マルチクラウド化が進むにつれて、各種クラウドサービスを比較する機会が増えるのではないかと思います。 今回は、自分の整理も兼ねて、Azure (Microsoft 365)/AWS/Google Cloud (Google Workspace)/OCI のサービス比較表 を作成してみようと思います。 *1*2 Azure/AWS/Google Cloud (GCP)/OCI サービス比較 マーケットプレース データベース ID WEB コンピューティング ストレージ セキュリティ 仮想デスクトップ 統合 分析 まとめ 参考情報 Azure/AWS/Google Cloud (GCP)/OCI サービス比較 マーケットプレース Azure AWS Google Cloud OCI マーケットプレース Azure Marketplace AWS Marketplace

                                                                【保存版】Azure/AWS/Google Cloud(GCP)/OCI サービス比較 - NOBTAの気ままにITブログ
                                                              • ZOZOTOWN「おすすめアイテム」を支える推薦システム基盤 - ZOZO TECH BLOG

                                                                はじめに こんにちは。SRE部MLOpsチームの田島(@tap1ma)です。 現在、ZOZOTOWNの「おすすめアイテム」に使われていたアイテム推薦ロジックを刷新するプロジェクトを進めています。既に一部のユーザに向けて新しいアイテム推薦ロジックを使った「おすすめアイテム」の配信を開始しています。その刷新に伴い推薦システムのインフラ基盤から新しく構築したので、本記事ではその基盤について解説したいと思います。 目次 はじめに 目次 「おすすめアイテム」とは 新しい推薦ロジック Recommendations AIを用いた推薦ロジック ZOZO研究所によって独自で開発された推薦ロジック 新しい推薦システム 推薦システムの処理の流れ システム構成 新しい推薦システムで工夫したポイント Bigtableのパフォーマンス改善 アイテム推薦APIのPodの安全停止 ZOZO研究所APIのキャッシュ戦略

                                                                  ZOZOTOWN「おすすめアイテム」を支える推薦システム基盤 - ZOZO TECH BLOG
                                                                • 協調フィルタリングとベクトル検索エンジンを利用した商品推薦精度改善の試み | メルカリエンジニアリング

                                                                  こんにちは、メルカリのレコメンドチームで ML Engineer をしている ML_Bear です。 以前の記事 [1] では、item2vecと商品メタデータを用いた、メルカリのホーム画面のレコメンド改善のお話をさせていただきました。今回は商品詳細画面でレコメンド改善を行ったお話をさせていただきます。商品詳細画面の例は図1の通りです。ユーザーはアイテムの詳細な説明を見たいときにこの画面に来訪するため、同様の商品を推薦する自然な接点として非常に重要です。 まず、私たちが商品詳細画面で行った改善の概要を示します。各部の詳細については次節以降で詳しく触れます。 日本有数の大規模ECサービスにおいてベクトル検索ベースの商品推薦アルゴリズムを実装し、推薦精度の大幅な改善を実現しました。 協調フィルタリングとニューラルネットワーク (以下、NN) を利用した商品推薦アルゴリズムを構築し、コールドスタ

                                                                    協調フィルタリングとベクトル検索エンジンを利用した商品推薦精度改善の試み | メルカリエンジニアリング
                                                                  • How to become a platform engineer | Google Cloud 公式ブログ

                                                                    ※この投稿は米国時間 2024 年 1 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。 あなたは Acme Corp という架空の会社のエンジニアで、CI / CD と自動化を用いたソフトウェアの統合と配信、データ主導型の指標およびオブザーバビリティ ツールの実装を行う大型プロジェクトに関わっているとします。しかし仲間のエンジニアの多くは、認知負荷が高すぎることで苦戦しています。Kubernetes クラスタのデプロイと自動化、CI / CD パイプラインの構成、セキュリティに関する懸念事項など、検討すべきことはさまざまです。会社の拡大と成長を支援するには、そのような課題の解決方法に関する考え方を改める必要があるとあなたは気付きます。そこで役立つ可能性があるのが、プラットフォーム エンジニアリングです。 プラットフォーム エンジニアリングは「コンピューティ

                                                                      How to become a platform engineer | Google Cloud 公式ブログ
                                                                    • Cloud Functions をローカル環境で統合テスト可能にした話 | BLOG - DeNA Engineering

                                                                      はじめまして。AIシステム部MLエンジニアリンググループ で学生インターンをしている 早坂( @takemioIO ) です。 普段はパケット処理などをやっているのですが、縁あってここでは MLOps の通常業務に携わっております。 私は二ヶ月間インターンとして開発に取り組んでいました。ここではその実装物の一つを紹介します。 この AI システム部 のとあるプロジェクトでは、 Cloud Functions と Cloud Pub/Sub を利用したデータパイプライン を構築しております。 そのプロジェクトは毎日のように変更が取り込まれ、非常に開発が盛んですが一方それゆえに破壊的な変更で足を撃ち抜いてしまいそれによって悩まされることがありました。 さらにはクラウドサービスを利用してるという部分からローカルでの検証環境がありませんでしたので、毎回 GCP に デプロイするしかなく、トライアン

                                                                        Cloud Functions をローカル環境で統合テスト可能にした話 | BLOG - DeNA Engineering
                                                                      • AWSエンジニアから見たGCPサービス(DB/ストレージ編)

                                                                        こんにちは、GMOアドマーケティング インフラ開発部のhakumaiです。 前回の記事「元AWSエンジニアがGoogle Cloud Professional Cloud Architectを取得した話」を読んでいただいた方々、ありがとうございます。 こんにちは、GMOアドマーケティング インフラ開発部のhakumaiです。前回の記事「PostgreSQLのメモリアーキテクチャを知る」を読んでいただいた方々、ありがとうございます。先日、Google Cloud のProfessional Cloud Architect(以下PCA)を取得する機会があったので今回はその合格までの道のりについてお話しいたします。きっかけきっかけとなったのは、Google Cloudが主催している特別トレーニング「G.I.G.」に参加する機会が巡ってきたことです。GMOアドマーケティングに入社して約1年が経つと

                                                                          AWSエンジニアから見たGCPサービス(DB/ストレージ編)
                                                                        • BigQuery におけるコスト最適化の ベスト プラクティス | Google Cloud 公式ブログ

                                                                          ※この投稿は米国時間 2019 年 9 月 25 日に Cloud Blog に 投稿されたものの抄訳です。 あらゆる業務のデータが各所に分散する今日の状況において、データ ウェアハウスの運営、管理は厄介で手間のかかる作業となりがちです。こうしたデータの急激な増加に対応してシステムをスケーリングし、日々の運用を維持することは、これまでになく大きな課題となっています。課題はそれだけではありません。データ ウェアハウスをアップグレードするときにダウンタイムをできるだけ短くする、ML や AI に向けた取り組みを支えてビジネスニーズに応えるなどの必要にも迫られています。Google Cloud のサーバーレス、エンタープライズ向けデータ ウェアハウスである BigQuery は、インフラ管理に手間を取られず分析作業に集中できるという点が評価され、数々の企業に導入されています。 BigQuery

                                                                            BigQuery におけるコスト最適化の ベスト プラクティス | Google Cloud 公式ブログ
                                                                          • ZOZOTOWNホーム画面におけるパーソナライズの取り組み - ZOZO TECH BLOG

                                                                            はじめに こんにちは、ML・データ部推薦基盤ブロックの寺崎(@f6wbl6)と佐藤(@rayuron)です。 ZOZOTOWNのホーム画面は2021年3月にリニューアルされ、「モジュール」と呼ばれる単位で商品が表示されるようになりました。 本記事ではユーザーごとにパーソナライズされたモジュール(以降、パーソナライズモジュール)のロジックやシステム構成、および導入時に実施したA/Bテストの内容と結果をご紹介します。 先に結論から言ってしまいますが、今回のパーソナライズモジュールでは機械学習モデルを使わず、ユーザーの回遊行動を分析した結果を元にしたルールベースのロジックを使用しています。本記事のポイントは大きく以下の3点です。 ルールベースのパーソナライズロジック 機械学習モデル導入を見越したシステム設計 ホーム画面のパーソナライズによる効果 本記事がこれから同様のタスクに取り組む方の参考にな

                                                                              ZOZOTOWNホーム画面におけるパーソナライズの取り組み - ZOZO TECH BLOG
                                                                            • ZOZOTOWNのおすすめ順を支える検索パーソナライズ基盤 - ZOZO TECH BLOG

                                                                              はじめに こんにちは、SRE部MLOpsチームの児玉(@dama_yu)です。この記事では、ZOZOTOWNのおすすめ順を支える検索パーソナライズ基盤について紹介します。 ZOZOTOWNのおすすめ順について ZOZOTOWNにおいて検索機能は非常に重要な機能の1つで、売上のうち多くの割合が検索経由です。ZOZOTOWNでは、検索結果の並び順として、おすすめ順、人気順、新着順など複数あり、現在おすすめ順がデフォルトになっています。 元々は人気順がデフォルトだったのですが、ユーザの嗜好に合わない商品まで検索結果に並んでしまうという課題がありました。そこで、この課題へのアプローチとしてユーザの行動履歴や属性を元にパーソナライズされた順番で検索結果を並べた、おすすめ順を新規追加することになりました。 この施策の結果、検索結果経由の商品CTRが向上しました。ユーザが求めている商品が並ぶようになった

                                                                                ZOZOTOWNのおすすめ順を支える検索パーソナライズ基盤 - ZOZO TECH BLOG
                                                                              • Feature Storeについてふんわり理解する - Re:ゼロから始めるML生活

                                                                                最近こちらのサイトを参考にfeature storeに関して勉強してみたので、今回はそのメモです。 www.featurestore.org Why:なぜ必要か? 機械学習の実運用時の困りごと 実験環境と本番環境を揃えたい 過去のある時点の状況を再現したい 特徴量に関する車輪の再発明をなくしたい 歴史的経緯 What:Feature Storeとはなにものか? 求められる要件 共有性 学習系と推論系の一貫性 Feature Engineeringと透明性 バージョン管理と再現性 ガバナンスとアクセスコントロール バッチとオンライン処理 How:どうやって実現する? 標準的なFeature Storeの構成 Serving Storage Transformation Monitoring Registory その他、主なプロダクト群 OSS Feast Hopsworks Rasgo マネ

                                                                                  Feature Storeについてふんわり理解する - Re:ゼロから始めるML生活
                                                                                • MonotaROのデータ基盤10年史(後編) - MonotaRO Tech Blog

                                                                                  こんにちは。データ基盤グループの香川です。 本記事は、MonotaRO のデータ基盤の歴史についての社内での発表の文字起こし記事の後編になります。 前編の記事: tech-blog.monotaro.com 前編では データ基盤の変遷の概要 2010年頃のデータ基盤 販促基盤とDWH(2010~2015) データ基盤構想とBigQueryの導入(2015~2017年) 同期システムの改良とBigQueryデータ基盤の展開(2018) までお話しましたが、後半たる本記事では以下について説明をしていきます。 他システムへのデータ提供とEC基盤の展開(2018) 2020年におけるデータ基盤へのデータ同期と利用状況 データ基盤の課題:データの管理体制の未整備による局所最適化 データ管理のグループ発足、Looker導入・DWH構築 歴史を振り返っての学び 歴史を振り返ることの意義 最後に 最後まで

                                                                                    MonotaROのデータ基盤10年史(後編) - MonotaRO Tech Blog