この記事はUbie Engineering Advent Calendar 2023の24日目です。主にInfra/Security/Reliabilityを担当している @sakajunquality がお届けします。胃腸炎により投稿が遅くなりました。胃腸のReliabilityは低めです。根クリスマスから年末にかけて体調を崩すと仕事もプライベートも大変ということが学びです。 さて本題ですが、今回は弊社チームのグローバル化について少しまとめてみたいと思います。 なぜグローバル化するのか？Short Answer: 社長の久保が「ん〜エンジニアのグローバル化したいな〜SREから！」と言ったので。 冗談です。それ自体は一つのきっかけに過ぎません。Ubie はJPだけでなくUSにも事業を展開しており、すでにグローバルチームが存在しています。しかしインフラや基盤のプラットフォームについてはグロー

はじめに早速ですが、皆さんはマイクロサービスを構築するとしたら、どのような構成を考えますか？ 多くの企業で、GKE を使ったマイクロサービス アーキテクチャが採用されています。選定理由として、Kubernetes が持つ機能や大きめなリソースが必要であったり、社内インフラチームによる Kubernetes のサポートがあるといった理由などがあります。一方、定期アップグレードなどの観点から、Kubernetes の運用は少し大変…と感じる方もいるかと思います。 GKE Autopilot の利用という考えもありますが、サーバーレスでコンテナを動かせる Cloud Run を使って、インフラ管理不要でマイクロサービスを構築が出来ると嬉しくないですか？ 実際、そういった構成を採用されている企業も見かけます。 この記事では、設計や実装時に考えるであろう、以下の 5 つのポイントにフォーカスしてみた

AmazonでMartin Kleppmann, 斉藤 太郎, 玉川 竜司のデータ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理。アマゾンならポイント還元本が多数。Martin Kleppmann… 手軽に扱えるデータの量や種類が増える一方、CPUの性能はムーアの法則通りには成長しなくなり、大規模データ処理では、多数のマシンを活用する分散処理が欠かせなくなってきました。クラウドの普及とともに多数のマシンを自ら調達せずとも分散システムを構築できるようにもなっています。 しかし驚くべきことに、今までこの分野に入門するための定番の書籍がありませんでした。分散処理にデータ処理が加わる融合分野である上、オープンソースプロジェクトの進化も速く、専門家同士でも共通の理解を構築するのが非常に難しかった分野です。この本を上手に使うと、既存のOSSプロジェクトの位置付けや、

These days a lot of people is using Jest’s snapshot testing on a daily basis. I will show you reasons why I stopped. We build spectacular apps, check auriosoftware.com FragilityWe changed a little bit of code and it blew off half of our tests. The problem is that these snapshots are highly coupled with our implementation and as we all know, coupling is one of the biggest pain in software developme

NTT OSSセンタの澤田です。NTT OSSセンタでは、PostgreSQLをより便利で強力なデータベースにするために、PostgreSQLコミュニティと連携してさまざまな開発を行っています。 近年PostgreSQLの適用領域が広がってきおり、金融系システムや、個人情報を扱うシステムにも適用したいという要望が高まってきています。NTT OSSセンタでは、PCI-DSS(クレジットカードのセキュリティについて国際規約)等のよりセキュリティ要件の高い環境でもPostgreSQLを利用できるようにするために、セキュリティ機能の強化に取り組んでいます。その中でも、保存データの暗号化を行う「透過的暗号化機能」は最も注力して開発している機能の一つです。 本記事では、開発中の透過的暗号化機能の概要や特徴について解説します。 PostgreSQLの暗号化における課題PostgreSQLはPGP暗号化関

qsona (twitter) です。以前、7,600行のコードを安全にこの世から抹消した話 という記事を投稿しましたが、今回はそれよりもずっと泥臭い話を書きたいと思います。あまりテクニカルな話はありませんが、現場における取り組み・試行錯誤の経過を読んでいただければ幸いです。 たくさん消しました、がんばりました〜背景肥大化するRailsサービスFiNCはマイクロサービスを指向しており、主にRuby on Railsで書かれたサービスが30個ほど存在します。しかし、FiNCアプリのメインとなるRailsのサービスは、テーブル数800を超える大きなサービスになっています。 FiNCのサービスは2014年から書きはじめており、かなり初期の段階(2015年)からマイクロサービス化を意識してきました。にもかかわらず1つのサービスが肥大化している理由はいくつかあります。 最初の1〜2年ですでに大量のコ

自分には子供が3人います。幼児が二人、乳児が一人（全員♂）。妻は働いていて、それぞれの子供が生まれて比較的すぐ職場復帰してます。三男の時にいたっては、彼が生後3ヶ月になる直前に職場復帰しました。 自分は基本的に朝8時半頃から仕事を開始し、4時に帰宅して、そこから父親業務をします（詳しくは数年前のこのエントリを参照）。そこで一日が終わりだと「あ、時短勤務なんですね」で終了なのですが、さすがにそれでは色々やるのに時間が足りない。自分はイベントの主催とかをやったりしてますし、それに通常業務もいくら午前中に気合いを入れて進められるだけ進めてもさすがにもう少し仕事をがんばらないとまわらないのです。なので夜に仕事ができる、ないし次の日のための余力を作るための時間を持てるというのはとても大事なのです。 幸い今のところ自分は子育てで忙しいなりにこうやってブログを書いたり、夫婦ともお互いに一人だけの時間を作

Apache Kafka: Producer, Broker and Consumer2017年は生まれて始めてApache Kafkaを本格的に業務利用（PoCではなく本番運用）した年でした。Apache Kafka的なメッセージングミドルウェアそのもののは、社内的な事情でよく使っていたのでその使い勝手に対して困惑はほとんど無かったですし、ミドルウェアとして非常に安定しているため、Kafkaクラスタそのものでの不具合らしい不具合が発生したことは一度もありませんでした。 しかし、Kafkaのトピック設計などに関してのベストプラクティスは事例ベースでもあまり見かけたことがなく、チームメンバーと悩むことも多かったです。このストーリーでは、主にKafkaを利用したアプリ設計で考えたことや失敗したことを振り返りつつ共有します。なお、パーティション数や各種バッファサイズなどのチューニング要素は今回取

この記事は、はてなエンジニア Advent Calendar 2017の 20 日目の記事です。19 日目の記事は yasuhiro_onishi さんのScratchを使った子どもへのプログラミング教育 — 大西ブログでした。 今年の 2 月にはてなに入社して、あと 1 ヶ月と少しで 1 年を迎えようとしています。はてなに入社してから Mackerel のインフラと時系列データベースの AWS 移行プロジェクトを任されたり、移行を終えた後も後片付けや移行後の運用を担当したりと、主に Mackerel にコミットしていた 1 年でした。自分が Mackerel にコミットしたところは Mackerel のイベントで登壇したいくつかの登壇資料にもあるとおり数多いのですが、この記事では、運用する中で試行錯誤を重ねて苦労した Mackerel を支える時系列データベースのコンポーネントとして利用

はじめにこんにちは、FiNCでSREを担当しているSatoshi Nakamuraです。 FiNCには半年前の2017年1月にジョインしました。 ジョインしてからほぼ ECS と Jenkins と戯れております。 今日はAWSの方にご協力いただき社内で開催した勉強会についてご紹介します。（SAの @akitsukada さん。本当にありがとうございました！！） 開催するに至った経緯FiNCのインフラ環境はAWSをメインに使用しているのですが、ご存知の通りAWSのサービスはインフラ以外もたくさんあります。 EC2、ECS、RDSなどは当然使用していますが、開発ツールやアプリケーションサービスなどは未だ使用していないものの、使用したら何か課題解決が出来るのではないかという期待と新しいものに触れたいという気持ちからAWSの方に相談して開催することになりました。 勉強会の内容を検討初のAWS勉強

【資料公開します】AWS Dev Day Tokyo 2017 にて登壇しました／choconの簡単なご紹介 - Mercari Engineering Blog こんにちは。SREの @ kazeburo です。2017年5月31日から6月2日にAWS Summit Tokyo 2017と同時に開催された「AWS Dev Day Tokyo 2017」に登壇しました。 登壇する機会をいただき、ま… 先日、というか昨日、この資料が流れてきまして、Private Networkの外部との通信を効率良く行うためのミドルウェア、choconというproxyサーバーが紹介されていました。SSL, HTTP/2を加味した上での超シンプルで高速なforward proxyサーバー実装という印象です。 使い方やAPIの叩き方は上記のリンクを参考にしていただくとして、やたらマイクロな実装でなぜこうも高速に

「社会人インターン」と称して2週間はてなのMackerelチームで働いてきましたので、その感想をつらつらと書きます。 おしゃれ感を演出している青山オフィスビデオチャットをいい感じに使ってるはてなといえば本社は京都ですが、東京のど真ん中、青山にもオフィスがあって、以前からビデオチャットでいい感じに中継したり会議したりしてる話は大昔からどこかに上がってた記憶がある。 Mackerel開発チームも東京、京都、その他にメンバーが散っていて、ビデオチャットは大活躍だった。朝会はそれぞれ zoom.us を立ち上げてみんなでビデオチャット。会議室で京都メンバーを交えた打ち合わせをするときは、備え付けのカメラとマイクで会議室の全景を写しつつ、大型モニターには京都の会議室の様子を写しているーというのが日常風景らしい。 こんなスペースでもビデオチャットできる用意がある先日 gitlab.com のトラブルで

Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.

世界中で話題になっているパナマ文書。各国で政権を揺るがすような事態にもなっていますが、純粋にデータとしてみた場合、これは計算機やデータ解析に関わる人々にも面白いものだと思います。データの中身や背景などについてはさんざん報道されていますのでここでは触れません。一方、現場でどのような作業が行われているのかはあまり報道されていません。現実的な問題として、人力ではどうしようもない量のリークデータを手に入れた場合、調査報道機関はどんなことを行っているのでしょうか？私も以前から疑問に思っていたのですが、先日あるデータベース企業と、データ分析アプリケーションを作成する会社のブログにて、その実際の一端を窺うことができる投稿がありました: Panama Papers: How Linkurious enables ICIJ to investigate the massive Mossack Fonseca

なんかFacebookへの投稿で「Augustのオフィスで凄い衝撃を受けた。日本のスマートロック会社はもう遅れすぎていてヤバイ」と煽るような事を書いたのが運の尽き。「ガタガタ言ってないで、早くブログで詳細書け！」と各方面からプレッシャーを受けてしまったSF在住中年起業家Kenです。ただ自分の考えの整理になる以外にも、やはりIoTというジャンル（？）をハード売り切りだけで捉えてしまうのと、本気でプラットフォームを目指すのとでどれだけ差が出るかを思ったより早く、具体的に示している事例かも？と感じたので整理してみる価値があると考えました。 サンフランシスコ市内のオフィス。プレスのために用意したデザインモックなどが綺麗に展示してあったり、評価用の様々なタイプのドアや鍵がずらりと並んだ倉庫のように広く、でも綺麗で素敵なオフィスでした。$50M調達とかすると色々とできていいなー（ボソ）。まぁそこじゃな