これはGo3 Advent Calendar 2019の2日目の記事です。 昨日はimotyさんの「とにかく要素一覧の取得が高速な、要素が削除可能であるリストを実装する」でした。 昨年後半から仕事で Go を書く機会が増え、使用している DB ライブラリ GORM を使う事が多かったので いちユーザーの視点から今年の動きについてつらつらと書きたいと思う。 GORM v1.9.2 以前 GORM は Go の ORM のひとつで、使い方などについては日本語での紹介記事も複数あるため改めて書く事もないが、 リポジトリスター数の多さなど知名度の面では Go ORM の中では上位に入るのではないだろうか。 …が、自分が仕事で使い始めてからは PR の消化も滞り気味で、2018年11月にリリースされた v1.9.2 を最後に新しいバージョンも出ず、 少し触っているだけでバグではないかという挙動もいく

この記事は Go Advent Calendar 2019 の2日目の記事です。 こんにちは！さいぺです。 サムネのGopherくんは最近趣味で描いたものを、せっかくなので載せました。 オリジナルのThe Go gopher（Gopherくん）は、Renée Frenchによってデザインされました。 さて、以下の動画を見てMiniSketchなるデータ構造があることを知りました。 MinisketchってIBLTを比較してメリデメとかあるんだろうか。そもそもどういうデータ構造使ってるんだろ。 【動画で学ぶブロックチェーン】Bitcoinの新しいTxリレープロトコルの提案 Erlay -　安土 茂亨氏 - YouTube https://t.co/mKB18CmWAF— さいぺ (@cipepser) 2019年11月13日 動画中のMiniSketchでは集合のreconcileまで述べら

まえがき まずは、RDBMSを実装するまでの、実装戦略(?)について説明します。実装戦略としては小さいシステムから徐々に機能拡張して大きくしていこう、という話をしました。具体的には3段階に分けてステップアップしていく予定です。ホップ・ステップ・ジャンプ戦略です。 1. シンプルデータベース 2. トランザクションサポートデータベース 3. リレーショナルデータベース シンプルデータベース シンプルデータベースは、データをインメモリで保持するキーバリューストアである。単発のCRUD処理ができる。少しイレギュラーな実装かもしれないが、データへのアクセスはDB側で振り出すオブジェクトIDのみでしか許されない。そのため、各カラムに対して、カラムの値からオブジェクトIDへのマップを保持する。シンプルデータベースでは、 テーブルを作成する データを挿入する データを取得する データを更新する データを

こんにちは。メルペイでバックエンドソフトウェアエンジニアをしている id:koemu です。 バッチプログラムのお話、今回は運用・監視についてお話したいと思います。当社はすべての業務が24時間行われていますので、システムがオンラインのときに動作するバッチプログラムについてのみ議論します。 過去の記事はこちらにあります。 運用に備えて バッチプログラムの運用について、「プリモーテム」「実行管理」そして「ログ管理」の3点について述べていきます。 プリモーテム ポストモーテムという言葉を聞いたことがある方はいらっしゃるかと思います。ポストモーテムとは、GoogleのSRE本の15章*1によれば、障害などの失敗を振り返り、今後に活かすプロセスの総称と捉えることができます。 さて、プリモーテム(プリモータム)とは何でしょうか。この言葉は、私が最近読んだThe Manager’s Path*2*3で使

こんにちは。メルペイでバックエンドソフトウェアエンジニアをしている id:koemu です。 今回は、前回の記事でお話したことを踏まえ、私が開発を担当して実際に動いているバッチプログラム「お急ぎ振込 締め処理バッチ(以下、締め処理バッチ)」について、述べていきます。 本記事では、「締め処理バッチについて」と「前回の記事に照らし合わせてどう設計されているか」の2点に分けて説明します。内容は、特に記載のない限り、本記事執筆時点のものとなります。 締め処理バッチについて 事例の話に移る前に、これから説明する締め処理バッチの処理がどのようなサービスを提供するのか、ご案内します。 お急ぎ振込とは お急ぎ振込とは、メルカリの中で売り上げたお金を皆様の銀行口座に出金できる機能の1つです。当初から存在している振込申請機能より早く送金することができ、最短1営業日で出金することが可能です。2017年の夏の終わ

こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する

仙石さんが志が高く優秀だけど,あんまり金銭的に恵まれない技術者のことを憂慮されている. 「技術力が高い人こそ、ビジネスモデルの良し悪しにもっと敏感になるべき」 http://sengoku.blog.klab.org/archives/64945422.html 志のある仕事(OSSの普及やボランティア活動など)は率直に言うとあんまり金銭的には儲からないことが多い．だからそこをメインの糧としてがんばり自分をすり減らすよりも,もっと効率いい方法で儲けておいて,余った余力で真にやりたいことをやった方が自分のためにも社会のためにもいいことだと思う． ただ仙石さんの言うように「だからビジネスモデルに敏感になれ！」というはまぁそうなんだけど,率直なところ「簡単に言うなよ」とも思う. だから私がもし本当に10倍パフォーマンスがあって志あって,真に自分のやりたいことのあるエンジニアだったら,会社には2倍

かなーり前にid:hirose31くんから献本いただいたんだけど,いろいろ思うところがありすぎて書評を書くのが遅れました. 献本ありがとう＆ごめんよ > id:hirose31 [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者:安井 真伸,横川 和哉,ひろせ まさあき,伊藤 直也,田中 慎司,勝見 祐己技術評論社Amazon もういろんな人が書評を書いているけれど「サーバ/インフラを支える技術」はとても良い本だ.LVSやDRBDなど「聞いたことあるけど,実績が不明で使うのをためらわれる」ような技術をDSASやはてななどの大トラフィックを受けるサービスで実践投入し,おそらくは試行錯誤の中,相当に痛い目を見てるはずだけど,そんなことはちっともおくびにも出さず我々に答えだけを見せてくれている

みなさんはAkamai Technologies社をご存知だろうか？ http://www.akamai.com/ http://www.akamai.co.jp/ Akamai社は高速なコンテンツ配信を請け負っている会社で,同社の保有する数万台のサーバリソースを利用しての大量の画像や大規模なストリーム配信を得意としている. アメリカではGoogleやYahoo!やMicrosoft,日本ではYahoo!Japanやmixiなどたくさんの会社が利用をしていて,インターネットを陰で支える縁の下の力持ちといった会社だ. 同社が提供するFreeFlowやFirstPointと呼ばれる配信サービスはまさにAkamai(ハワイ語でCoolの意味)というにふさわしく,初めてそのバックのテクノロジーを教えてもらったときは目から鱗が落ちる思いだった. ところで9/11は言うまでもなく米同時多発テロが起きた

ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し

明日はアドテック東京というデジタルマーケティングのカンファレンスが行われる。 最近広告配信周りでRTB(RealTimeBidding)というシステムがはやりつつあるが、RTB用のADサーバこそ最強である必要があるということを述べてみたいと思う。 RTBの仕組みというのは簡単に言うと下記のような感じになる。 1. 広告サーバ(SSP)に問い合わせがあった場合、バックに接続されたRTBの広告サーバ(以下RTBサーバ)に対して問い合わせをオークション形式で行う 2. RTBサーバは来たリクエストに対していくらで購入ができるかを返し、SSPは最も高い単価をつけた広告をユーザに返し、表示する(CPMというのは広告単価だと思えばいい) 上記の処理を1つの広告表示のたびに行うので、Real Time Bidding(RTB)というわけだ。RTBのエコシステムにおいては自分の都合のよいユーザのアクセスの

地震速報の話 Iさん：ヤフーの全ページに一気に情報を反映させる仕組みってないかな？ yamaz：  広告サーバはどうですかね？設備はもうあるし、クリックや表示カウントもできますよ。 1秒間に数万アクセス――地震発生時にYahoo! JAPANトップに現れる“あの枠”の裏側 - Yahoo!ニュース スタッフブログ 当時ヤフーの全ページに一気にデータを反映させる仕組みは広告サーバしかなかったので、地震速報の実装は広告サーバをベースに行われた。もう10年ほど前の話だ。 Contents Delivery Managementという考え方 弊社はいわゆる広告システムを作っている会社だけど、広告システムを9年前に作ろうと思ったときに「広告システムって結局のところなんなのだろう？」というのを非常に考えた。いわゆる「バナー配信システム」を作ることはもちろんすぐできたけれど、今後ありとあらゆるインターネ

PHPカンファレンス2019 LT ブログ記事もあわせてお読みください！ https://tech.connehito.com/entry/heartful-code-review

この記事は Supership株式会社 Advent Calendar 2016 - Qiita の1日目の記事になります。遅くなりました。 Supership CTO室室長 @yamaz です。 ビビりなエンジニアが大企業を辞めて起業した話を書きます。 スケールアウトを立ち上げる前、私はヤフージャパンに務めていた。 当時私は結構な給与をもらっており、かつそこそこの立場におり、かつ仕事も面白く、普通なら辞めないような立場だった。 だけど思うところがあり、会社を辞めその後会社を作ることになった。今回はそのあたりの話をしようと思う。今から10年ほど前の話だ。 きっかけ きっかけは上司からの命令だった。 「Adsense作って。2人で」 なんとなくそれっぽいものを作ったものの、エンジニアとしての自分に疑問を持つ結果となった。 AdSenseのすばらしさとのギャップ AdSenseはすごいプロダク

TL;DR 平文のTCP/IPの通信では送信したデータの完全性は期待できないので、経路にはSSL/TLSを使いましょう TCP/IPはUDPと違い、信頼性のある通信を実現するためのプロトコルという説明がよくされる。なのでTCP/IPでやり取りしたデータは1bitの狂いもなく転送先に届くと思われがちだ。TCP/IPが信頼性のある通信を確保してると言われているのは下記の理由による。 1. データが届かなかった場合の再送処理がプロトコルに入っている 2. TCPパケットにペイロードのチェックサムがあり、不具合が検知されると修正もしくは再送される(ただし16bit) 3. IP層の更に下の層にチェックサムがあり、不具合が検知されると修正もしくは再送される(イーサの場合32bit) しかしチェックサムはそれぞれ16/32bitのため、昨今の超大量データを取り扱うにはかなり心もとない。 1. ざっくり

これは Supership株式会社 Advent Calendar 2018の25日目の記事です。 Supership株式会社 CTO @yamaz です。 広告システムエンジニアは絶対におもしろいと思う理由 という記事をちょうど10年前に書きました。 今回はあれから10年経って現在広告システムエンジニアをとりまく環境ははどうなっているかについて書きたいと思います。 TL;DR (３行で) 10年前と変わらず技術的、学術的、ビジネス的にエキサイティングな領域だよ。 広告テクノロジーをプレイヤーが切磋琢磨し続けてきた結果、大規模配信・集計技術もさることながら大規模データ分析や運用技術の領域も大事になってきたよ。 まだまだ課題満載な業界だけど、デジタルマーケティングに未来を感じてる人はぜひ広告業界へ応募を！ 10年前と変わらず技術的、学術的、ビジネス的にエキサイティングな領域である 10年前は

誰でも簡単に高品質なスマホアプリを開発・運用できるプラットフォームを運営する株式会社ヤプリ。導入実績は400件を超え、アプリ開発のノウハウを持たない事業会社のモバイル戦略を支えています。 この度、Go ConferenceをはじめとしたGoコミュニティの運営者であり、Google Developer Expert(Go)でもある上田 拓也さん（@tenntenn）がヤプリの技術顧問に就任しました。「Goコミュニティへの貢献」をミッションに掲げるtenntennさんと、「Mobile Tech for All」をミッションに掲げるヤプリで様々なチャレンジを推進していきます。 今回はCTOの佐野がインタビュアーとなり、tenntennさんのミッションやGoへの想い、ヤプリに感じた魅力、今後の取り組みの様々な可能性についてお話いただきました。 ■プロフィール 上田 拓也（@tenntenn） メ

この記事は本番環境でやらかしちゃった人のアドベントカレンダー２日目の記事です。 内容的にそろそろ時効だと思うので供養のために書きました。 追記。そういえば時期をちゃんと書いてなかったけど事件が起きたのは去年2018年、つまり仕込み（ヲイ）は2017年の話です ぶっちゃけネタ記事ですｗ （たまたま見つけて参加してみただけなのに昨日の記事の伸びっぷりを見て戦々恐々としてる TL;DR DB移行作業において、テスト期間中は常に最新のデータで処理できるように書いておいたプログラムをcrontabで実行していた。最終的に本番に合わせて日時を調整していたが、そのことを失念し１年後に再実行されてしまい、本番データが１年前に巻き戻る事故発生。 crontab は分、時、日、月、曜日を指定できるが、１年後に帰ってくるから気をつけてね。という話。 惨劇はなぜおこってしまったのか 結論から言えばcrontabの

本記事はDMMグループ Advent Calendar 2019の1日目の投稿です。 どうもこんにちは。DMMで動画の配信基盤を作っているチームでプロダクトオーナーをやっているyanoshiです。 数日前に見たらアドベントカレンダーの1日目が開いてるじゃないですか！ってことで確保した1日目です。私なんかが1日目で良かったのだろうか。 どんな話を書こうかなと思ったのですが、メモ書き程度にちょっと調べたいことがあったのでそれについて書きたいと思います。 動画コーデックの話です。 注意(お約束): 本記事の内容は所属する組織との関係は一切ありません。全て筆者の個人による調査/私的見解であり個人利用の範疇による技術的検証となっています。 また本稿の内容を実施して発生したあらゆる損害を筆者は一切保証しません。 概要 本稿ではAWSの c4.8xlarge インスタンスを用意し、下記のエンコーダーそれ

はじめに 今回の動画 余談 Advanced SQL SQL History 準備 集計 文字列操作 出力のリダイレクト 出力制御 ネストしたクエリ Common Table Expressions おわりに この記事は「 けんつの１人 DBMS アドベントカレンダー Advent Calendar 2019 - Adventar 」 2日目の記事です。 はじめに どうも、最近なになになけんつです。という始まりをあと 24 回もやらないといけないのかと思うとネタ切れが心配になるけんつです。 ちなみに最近みて面白いなと思った映画は「ローン・サバイバー」です。 例によって CMU Database Systems を進めていきます。今回は「Advanced SQL」です。 今回の動画 www.youtube.com 余談 この講義、現在進行形で2019年版が展開されているみたい。 この記事を書

ふと思い立ち、1人でRDBMSを実装することにしました。RDBMS(Relational DataBase Management System)、つまりOracleとかPostgreSQLとかそういったのを1人で作ってみましょうという企画です。 やりたいことは2つ 1. 誰でもRDBMSを実装できるように、実装部分を細かく説明すること 2. マイRDBMSに何か特別な機能を盛り込むこと 誰でもRDBMSを実装できるように みなさんは「OS自作入門」、「CPUの創りかた」など、難しそうでとっつきにくいものを簡単な機能に分解し、しかも自分で作れるようにしてくれるとても親切な本を読んだことがありますか。しかし残念なことに、RDBMSの作り方を教えてくれる本はなさそうです。無いものは作りましょう。 ここでは、PostgreSQLのソースをひとつひとつ見せながら、ここはこういうことをしている、、、と