みなさんこんにちは、ソラコム 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 内で規定されることになったサイトリライアビリティエンジニアリングとは、

いつも Backlog をご利用いただきありがとうございます。 今年の8月に入社し、Backlog SRE チームのメンバーとなった吉澤です。前職ではソフトウェア開発者として働いていましたが、DevOps 的な活動にも長年興味があり、このたびヌーラボに参加しました。これからよろしくお願いします。 本日は、2018年1月に予定している Backlog リリースについて、事前にご連絡します。一部のお客様では、設定変更が必要になる可能性がありますので、以下の内容をご確認お願いします。 変更点 SSH 接続のセキュリティを向上させるため、2018年1月10日(水)より順次、Git SSH 接続でサポートする公開鍵および鍵交換アルゴリズムを変更します Git クライアントで古い鍵交換アルゴリズムを設定している場合は、事前に設定を変更いただく必要があります サポートする公開鍵の追加 アップデート後は、

個人的に、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

次世代システム研究室アーキテクト兼データサイエンティストのT.Nです。 私は文系卒ながらもデータサイエンティストという役割を頂いている、いわゆる「文系データサイエンティスト」です 「文系でもデータサイエンティストにはなれる」と言われていますし、私もそうだと思っています ただ「機械学習や統計の理論を知らなくてもいい」というわけではありません 程度の差はあれ理論学習なくてして、分析を実施することはやはり難しいかなと しかし数学知識や理論、統計学の裏付けが無いためどうやったらいいか途方に暮れることもあるかと思います そんな環境に直面した私が機械学習関連の理論を勉強した際の方法を記載しようかと思います 同じ悩みを抱えている方の参考にでもなれば幸いです 目的 私と同じように文系卒でデータサイエンティスト職に就いている方、もしくはこれから機械学習関連の勉強をしていこうとしている方に対して 私の勉強法を

こんにちは、次世代システム研究室のN.O.です。 先日部内の研究発表会でブロックチェーンについての発表を行いましたので内容を共有したいと思います。 私の受け持ちとしてブロックチェーンの概要、またブロックチェーンを語るには欠かせないその発祥となったBitcoinについての説明を行いました。スライドのタイトルには「その未来」とありますが、未来の部分は今回は省略させていただきます。今後、別の機会で発表したいと思います。 イメージしやすいようにブロックチェーンを簡単な図にしたものです。 ブロックの中にトランザクションがこのように複数入ってます。 そこにブロックのヘッダとして前のブロックのヘッダのhashやnonce、マークルルートといったものが入ってます。 これらが一つになってブロックを成し、それらが鎖のように連なっていきます。 おおよそこのような形です。 ブロックのヘッダにはマークル木によって全

こんにちは。次世代システム研究室のY.I.です。 最近参画した歴史あるプロジェクトで行ったトラブルシューティングの話題です。 アプリケーションの概要は CentOS 上の Tomcat で動作するサーバサイド Java アプリケーションとなっています。 今回は 「メモリ不足によるトラブルの対処」と「Java スレッドがデッドロックしてしまった件」をどのように調べて解決したかをお伝えします。 ◆メモリ不足によるトラブルの対処について 連携先との兼ね合いで Tomcat サーバから Apache サーバへ ssh して連携媒体と通信する機能がありました。こちらが2日に1回程度エラーになり Tomcat を再起動するまで失敗し続けるという状況になっていました。 エラーログ ERROR [InitAction.postProcess:132] ssh error web server ip=192

2016.03.11 実サービスで利用中のAnsible 1系をAnsible 2.0にアップグレードすると、何が起こるか？ 次世代システム研究室の DevOps ネタ担当の M. Y. です。 今年の1月に、構成管理ツール Ansible のメジャーバージョンアップ版である Ansible 2.0 がリリースされました。 この Ansible 2.0 では今後の機能追加を容易にするために、内部構造がほぼ一から書き直されています。その成果として、複数のタスクをまとめる block 構文や、200個を超える新規モジュールなど、多数の機能が追加されました。その一方、既存の playbook（処理内容が書かれた YAML ファイル）との後方互換性を維持することも、Ansible 2.0 の大きなゴールとして謳われています。 私たちも、いくつかのサービスで Ansible を実際に使用しており、そ

embulk-input-jdbcでこんな問題が上がっていたので、データベースのタイムゾーン付の型について調べてみた。 MySQL (5.6) ドキュメントを見ると、TIMESTAMP型はタイムゾーンに対応しているらしい。 DB内ではUTC、クライアント側ではtime_zoneシステム変数で指定されたタイムゾーンになるようだ。 実際に試してみる。 mysql> show variables like '%time_zone%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | system_time_zone | UTC | | time_zone | UTC | +------------------+-------+ 2 rows in set (0.19 sec

実にふざけた話である。 軽減税率：有害図書、出版業界で線引きを　菅官房長官 – 毎日新聞 要するに、出版物に軽減税率を適用させるなら、「有害図書」を対象から外すということである。ただし、政府が「有害図書」を決めると検閲にあたるから、出版業界自らが生け贄を差し出せと。 菅義偉官房長官は、「出版界が自主規制し、例えば議員立法という形で、国民から見てなるほどという線引きが必要だ」と発言しているが、立法に反映することを前提として求められる「自主」規制とは何なのか。そんなものはただの責任のアウトソーシングであって、本来追うべき責任を回避せんとする目眩ましにすぎない。 そもそも「有害図書」などという言葉自体、実にレッテルに満ちたものなのだ。あくまでも「青少年の健全な育成に有害な（影響があるという社会共通の認識がある）図書」である。世間では天動説を信じられているからそうなのだというレベルの脆弱な根拠にも

先日HashiCorp社の新プロダクト、ottoがリリースされました。 Vagrant の後継ツールという位置付けであるということで、Vagrant 好きの自分はすぐに飛びついてみます。 otto のインストール まずは otto をインストールしましょう。 とはいえ otto もワンバイナリのツールであるため、ダウンロードしてきたモジュールをパスの通った場所に保存すれば全て完了です。 $ sudo mv otto /usr/local/bin/ $ otto usage: otto [--version] [--help] <command> [<args>] Available commands are: build Build the deployable artifact for the app compile Prepares your project for being run