こんにちは。運営スタッフの@nari です。 いよいよSRE NEXT 2020の先行販売チケット販売がスタートしました!! 今後販売する一般販売チケットよりも安く購入することができます。 数量限定となっておりますので、是非お早めにご購入ください。 チケット購入はこちらから！！ 予定イベント 本編 懇親会 先行販売チケット購入ガイド 1.購入するチケットを選ぶ 2.Eventriteのアカウントを作る(or ログインする) 3.チケットの購入手続き 4.Paypalで支払いを行う 5.購入後の確認 6.QRコードの準備 6.1 アプリのインストールとログイン 6.2 チケットのQRコードを表示する 購入済みチケットの譲渡 チケット譲渡される方 1.該当チケットのattendeeの情報を修正し、チケットを譲渡する 2. チケット譲渡後 チケットを受け取る方 予定イベント 本編 2020年1月

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

ヌーラボでScalaを書くRubyistの谷本です。ヌーラボでは、Backlogの開発を担当しており、最近ではBacklogをJavaからScala / Play Frameworkに移行するプロジェクトのメンバーでした。 BacklogのPlay化プロジェクトでは、OutOfMemorryError(以下、OOM)の発生やCPU使用率とロードアベレージが上がったままという、Java Virtual Machine（以下、JVM）上で動くBacklogのパフォーマンスに関する問題に対処すべく、何度かHeap/Thread dumpを見る機会がありました。 私がPlay化プロジェクトで取り組んだパフォーマンス改善の知見や経験をもとに、本記事では「JVMで起こったパフォーマンスの問題の切り分け方」についてお届けします。 はじめに 本番環境でしばらく動かしていると、コード自体は正しく実行できるけ

ヌーラボの江口です。約8年間Backlogの開発を担当しており、BacklogをJavaからScala / Play Frameworkに移行するプロジェクトには最初から最後まで関わりました（プロジェクトの概要は時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話をご覧ください）。 本記事では、BacklogのScala / Play Framework化プロジェクトで「Backlogのサーバーサイドを進化させる“土台”を作る」をテーマに、どのようにBacklogのアーキテクチャを設計・実装したのかご紹介します。 はじめに 私は2012年の入社以来、Backlogの開発を担当しています。Backlogは10年以上続くサービスであるため、度重なる機能追加や修正を行うことで複雑化し、日頃開発をする上で様々な問題を感じていました。 今回のBacklogのSca

ヌーラボの松本です。「Backlog Playプロジェクト」に2017年2月から途中参加し、プロジェクト解散の2019年7月までメンバーの一員として動いていました（プロジェクトの概要は 時系列でみる！4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話をご覧ください）。 このBacklog Playプロジェクト(以下、Play化プロジェクト)では、期間によって私の役割は変わりました。 参加した当初は開発メンバーとしてコードを書いていましたが、2018年4月からプロジェクト終了の2019年7月までは、開発をしながらプロジェクトの取りまとめをしていました。 マネジメントのような役割ははじめてだったので、いろいろ未熟な点もありましたが、プロジェクトの機能リリースを早めるために、不具合対策や手戻り削減といった問題と向き合いました。 本記事では、私のPlay化プロジェクトでの役

ヌーラボの松浦です。私がSREのエンジニアリングマネージャーとしてプロジェクトのサポートに携わっているプロジェクト管理ツールのBacklogは、2019年7月にJavaからScala / Play Frameworkに完全移行をしました。 このPlay化プロジェクトは、10年がかりで改良され仕様が明文化されていなかったBacklogを、JavaからScala / Play Frameworkに移行するという壮大なプロジェクトでした。 約4年にわたる「Backlog Playプロジェクト」(以下、Play化プロジェクト) で体験した“紆余曲折”を記録に残し、後のプロジェクトにつなげるために、今回から7回に渡って、技術的な挑戦やプロジェクト管理の視点など、当時のチームメンバーが独自の目線でPlay化プロジェクトを振り返った記事を連載します。 連載第1回目の本記事では、序章としてPlay化プロジ

SRE NEXT CFP Open こんにちは。スタッフの @chaspy です。 先日、SRE NEXT の CFP を Open しました。 https://docs.google.com/forms/d/e/1FAIpQLScrcabZm4pnzI8PZnKA6-CO2TtswPU60vm_HZZo5cKPGcDkyg/viewform 本 CFP は締切日までなんども修正できるので、今すぐ仮タイトルだけでも入力することをオススメしています。 すでに Talk Proposal が届きはじめており、多くの Proposal が揃うことを楽しみにしています。 本記事では、どのような Talk を募集しているのか、あるいはどのように CFP に応募したらいいのかについて簡単に説明します。 なぜ Talk を公募するのか SRE NEXT では 招待講演 と スポンサーセッション の他に、

2013年に「日経電子版」のソフトウェア開発を内製化し、アジャイル開発に切り替えた、日本経済新聞社。開発サイクルはもちろんチームの抜本的な改革は、多くの注目を浴び、400以上のはてなブックマーク数を獲得しました。 アクティブユーザーを1.9倍増にした内製化の成功をきっかけに、2017年には日経電子版のコンテンツの表示速度を改善する「爆速電子版」プロジェクトを実施し、業界最速のスピードを実現しました。 内製化やアジャイル開発の開始から6年が経過し、日経では開発部門だけでなく、全社的な組織改革に着手しています。そこで、同社の現役プロダクトマネージャーに、日経が挑戦する開発の現場の“いま”についてお伺いしました。 ■自己紹介（右から） 情報サービスユニット 斎藤祐也（さいとう・ゆうや）さん デジタル編成ユニット プロダクトマネージャー武市大志（たけいち・たいし）さん デジタル編成ユニット 西馬一

DOZAN11(元 三木道三)とXamarin開発の第一人者が語る、アーティストと開発者の協創とコミュニケーションのヒント スマートフォン向け音楽自動生成&動画作成アプリ「mupic」は、画像の色を解析して、その配色や明るさなどから出来たオリジナルの楽曲が付いた動画を保存できるプロダクト。このアプリケーションの開発を手がけたのは「Lifetime Respect」で爆発的なヒットをした三木道三ことDOZAN11氏とXamarin開発の国内第一人者でもある青柳臣一氏が代表取締役を務める「株式会社ディーバ」。 mupicの開発秘話から垣間見えた、アーティストと開発者、ユーザーとの「協創」の精神。それを実現するための「コミュニケーションのヒント」についてお話をお伺いした。 ■プロフィール（写真左から） DOZAN11：96年、「三木道三」名義でジャマイカ拠点のレーベルからデビュー。2001年に発

みなさんこんにちは、ソラコム shokiです。春と花粉の気配を存分に感じる3月が過ぎました。この一月の間では、3/13にSRE Lounge #8、3/30にSORACOMUG 信州#6が開催されました。このイベントに触れつつ、今月もIoT記事をまとめていこうと思います。 SRELoungeの参加レポート SRE Lounge #8 のメモ SRE Lounge #8 の感想（取り入れたいと思った活動の話を中心に） SRE Lounge #8 に行ってきた 今回、ソラコムではSRE Lounge #8にてソラコムでの開発･保守体制を紹介させていただきました。ソラコムからのレポートはこちらで公開しているので、ぜひご覧下さい。→SRE Lounge #8 に参加しました！ IoTというよりは、分野問わずあらゆるサービスの開発や保守体制をいかにうまくやるか?という話です。IoTがハードウェアを売

SRE Advent Calendar 25日目の記事です。 SRE Advent Calendar 2018 - Qiita SRE 2 Advent Calendar 2018 - Qiita SRE Advent Calendar を振り返ります。 全記事の振り返り Day1 SRE Advent Calendar の1日目公開しました！！！ 監視システムを網にたとえて特徴を記述してみました。 はてなブログに投稿しました #はてなブログ [SRE Advent Calendar] 監視システムの特徴…https://t.co/yq1XXVuMkG — かつひささん (@katsuhisa__) 2018年12月1日 Day2 SRE Advent Calendar の2日目！ 地道に一つずつはじめようとしている話でよい。 引き続き応援しています！！！ 弊社におけるSREという考え方の

これは SRE Advent Calendar 11日目の記事です。 こんにちは、Backlog の SRE を担当している吉澤（Muzi と呼ばれている人）です。 本記事では、SRE Lounge #5 で講演した際に、時間の都合で省略した「ヌーラボ社内での Backlog のサービスレベル計測とその結果の活用」についてご紹介します。 長年運用されてきたサービスを改善するために、SRE ができる取り組みの一例としてご参考ください。 SRE とは？ SRE とは、Site Reliability Engineering の略です。これは Google で初めて提唱された概念で、その提唱者自身は著書「SRE サイトリライアビリティエンジニアリング」（いわゆる「SRE 本」）のなかで以下のように述べています。 Google 内で規定されることになったサイトリライアビリティエンジニアリングとは、

鍵交換アルゴリズムのご確認方法 Git SSH 接続に利用しているソフトウェアのマニュアルをご参照いただき、現在お使いの鍵交換アルゴリズムをご確認ください。もし古い鍵交換アルゴリズム（diffie-hellman-group1-sha1）をお使いの場合は設定の更新をお願いします。以下は git コマンドの場合の例です。 例：git コマンドの場合 git コマンドは、SSH 接続に OpenSSH を使用しています。そのため、OpenSSH の設定ファイル（~/.ssh/config など）をご確認ください。以下のような設定がある場合、鍵交換アルゴリズムが diffie-hellman-group1-sha1 に固定されています。 KexAlgorithms diffie-hellman-group1-sha1 この設定がある場合、設定ファイルからこの行を削除していただくか、以下のように

個人的に、Nginx で「これは危険だ」と思っている設定があって、Nginx でなにかあるたびにその設定をつい疑ってしまいます。その設定について他の人に話すたびに、いちいち資料を集めるのが面倒になってきたので、今回はその設定項目についての情報をまとめておきます。 まだ理解に自信がない部分があるので、新しい情報が入ってきたら、この記事を適宜修正します。 リバースプロクシ設定の基本 Nginx をリバースプロクシとして使う時には、ngx_http_upstream_module でサーバのグループを定義します。そして、サーバ名やロケーション（パス）に対して、送信先のグループを指定します。 以下はマニュアルにある例です。その Nginx サーバへのすべてのアクセスを、backend グループに指定されたいずれかのサーバに送信します。 upstream backend { server backe

ようこそ、サル先生のWiki入門へ。ここは、主に仕事の組織やチーム内で情報共有をしたい方に向けて、Wiki（ウィキ）を使った情報共有の方法を解説するサイトです。「入門編」では Wiki を使うことによるメリットと、基本的な使い方を解説します。「実践編」では Wiki の具体的な操作方法や、Wiki を使った情報共有のコツを解説します。

Markdown Night 2017 Summer - connpass で色んな話を聞けて刺激を受けたものの、その後の懇親会で自分の問題意識・欲求がいまいち上手く伝わらない・伝えられないことに気づいたので、自分なりに整理(?)しておきます。 TL; DR. 社内マニュアル向けシステムには、情報の構造化と新陳代謝を支援して欲しい 10年以上前から Wikiの一つを チーム内マニュアル書きに使ってきたものの、長年不満を感じている。 Wiki も色々有るし、更にもっと良さげな情報共有サービスも色々出てきたので、 実は既にこの問題は解決されているのかもしれないけれど… とにかく自分の問題意識を書き下しておきたい。 オーソドックスな Wiki の特性 ページはページの名前で識別されリンクされる (例外： tcler’s wiki) ページの追加は、既存のページに（新ページへの）リンクを書くことで

D. M. です。昨今はテキスト解析が非常にやりやすい時代になりました。チーム内でも活発に検証・活用されており、私も流れに乗って Word2Vec や Doc2Vec を触りだしましたが、参考になる日本語の記事多いですね。よくあるのはニュース記事・青空文庫・ Wikipedia の解析ですが、各社の独自の文字列データ、しかも結構なサイズのデータを食わせて関連語を出す記事などもあったりして、実利用可能かどうかは関係無しに楽しそうです。 やりたいこと 類語判定について、ウェブ上では既に相当いろんな種類の記事を上げられていて凄いなあと思いつつ、結構簡単に見えたので私も何か検証しようと思いました。ただ同じことをやってもあまり面白みが無いですし小規模でも始められるようなことを考えて、ひとまず自分の Twitter のつぶやきを食わせて類語を見てみることにしました。今日はそんな初歩的な試みの紹介です。

こんにちは、次世代システム研究室のN.O.です。 先日部内でnginxのproxy_next_upstreamの挙動についての共有があり、ロードバランサーとして設定する際に気をつけるポイントがあることを知りました。現在のプロジェクトでもちょうど環境を整備しているところでしたので、調べた結果を共有します。nginxを既に運用されている方にとっては何を今更、という内容ですがご了承ください。 本ブログ時点でのnginxのバージョンは1.10.3です。 proxy_next_upstream ロードバランサーの設定を見る前にproxy_next_upstreamについて解説します。proxy_next_upstreamはロードバランス先となるupstreamのサーバがトラブルなどで応答出来ない時などに、別のサーバにリクエストを再送します。なお再送されるのはGETなどのメソッドとなっており、POST

レガシープラットフォームの改善を担当している D. M. です。ログの重要性が高まる昨今皆さんはいかがお過ごしでしょうか。 モチベーション 私の担当するシステムでは、エンドユーザが画面を操作するリクエストや外部システムからの API リクエストを前段の Web サーバが一元的に受け付けています。この状況下でお問い合わせや不具合が発生した場合の調査をしやすくするために GET なり POST なりで受け取ったデータを全てログに出したいというニーズが出てきました。ですが、リクエストにはメアドやパスワードなどあまりログに残したくない情報も流れてきます。今回はそれらを Web サーバがフィルタする仕組みについて取り扱いたいと思います。 対象者 ・ Nginx を普通に使っているがそんなに凝ったことはしていない。 ・ Nginx ログをいじり倒したい。 やりたいこと 目的は以下の2つです。 ・Ngi

こんにちは。次世代システム研究室で Hadoop 周辺をよく触っている T.O. です。 Hadoop 周辺をよく触っているので、最近 Hadoop 周辺を触ってきて得た話などを書いていきます。 少し前に HDP 2.5.0 が正式にリリースされました。 HDP 2.5.0 では、 Hive LLAP が Technical Preview 扱いではありますが、用意されています。ということで、今回はその Hive LLAP を試してみました。 Hive LLAP の紹介 Hive LLAP については、下記のページやスライドを読むと、敢えてこのエントリでまとめなおすまでもなく、理解が進むと思います。 https://cwiki.apache.org/confluence/display/Hive/LLAP LLAP: long-lived execution in Hive LLAP: S