エッ、また進化したの！

中国 アドベントカレンダー2019

改めまして、こんにちは。BBSakura Networksの夏(@xia)です。
この記事はBBSakura Networkのアドベントカレンダー 23日目です！ 多分中国テクノロジーに関する様々な記事があると思いますが、ここでは自分の経験とそれの感想について書きたいと思います。

私は高校卒業後、来日し今でも年１回や２回中国に帰ります。こんな頻度で帰国しても、その度に、「エッ、また進化したの！」と思ってしまいます。

先月、中国のお店で会計する際に、店員さんに当たり前な感じで「支払い方法はアリペイ、それともwechat payですか?」と聞かれました。現金しか持ってない私は「あっ、、現金です」と回答したら、まるで田舎から来た娘と見られてしまいました。
スーパーで買い物した最後、店員さんに会計してもらおうと思ったのに、弟は「先ほど箱に入れたものを全部自分でスマホでスキャンしてたので、既にスマホで自動会計済で、あとは店員さんがそのリストと買った商品を確認するだけでいいよ」と言ったら、「エッ、また進化した」としか言えないです。

出前デリバリーサービス(外卖)は出前デリバリーサービスだけではない

中国の街ではユニフォームを着てる出前の配達員をよく見ます。 出前デリバリーサービスが普及されてる為、ランチタイムには、ほとんどの方は出前を注文し、ほぼ30分以内指定場所に届けられます。iiMedia Researchのデータにより、2018年の中国の出前注文するユーザーの規模は2017年と比較して17.4％増加し、3億5800万人に達し、2019年には4億人を超え、その成長率はまたまた続くと言われています。
そのアプリ機能は主に
　・注文・評価機能
　・オンライン会計機能
　・配達員居場所がリアルタイムで確認機能(GIS)
ぐらいだと思う方が多いかもしれませんが、実際にはそれだけではありません。 これはとある出前注文アプリの操作画面です。出前注文アプリなのに、ホテル予約、タクシー呼ぶ、映画館チケット予約、医療方面、様々なサービスも含めています。また、デリバリー内容は出前だけではなくて、欲しいもをデリバリーのお兄さんに頼めば、ほとんど届けてくれます。近年、夜間に胃薬や風邪薬など非処方せん薬を買えるようなサービスも出てきました。
中国では、デリバリーお兄さんが「世の中で届けられないものはほとんどない」とよくに言われています。
本当に便利です、もし中国へ行く機会があれば、ぜひそのサービスを体験してみてください。

Wechatはchatだけではない

Wechatは中国版Lineです。中国では日常生活に欠かせないアプリだと思います。
この前、中国ホテルを予約しましたが、色々リクエストがあるため、相手のwechatを追加しました。店員さんがほぼ２４時間対応してくれて、現地の写真や天気情報は全てwechat経由で提供してくれました。中国ではビジネスの場合でも、wechatでコミュニケーションするのは主流です。日本で電話かメールしか問い合わせできないことと比較して、それに本当に感動しました。
もちろん、チャット機能以外、水道光熱費用、会社保険支払い、携帯・インターネットなど費用チャージなど、様さまなオンライン会計サービスを提供しています。
第三者提供されるサービス、タクシー呼ぶアプリ、デリバリーアプリ、オンラインショッピングアプリもwechatと連携して利用できます。saasを提供されている為、技術者が簡単にアプリを開発するのもできます。
一方人口が多い中国では、病院の予約は社会問題です。wechatはそれに対して、2016年からオンライン病院予約サービスを提供始めます。携帯の位置によって、そのシティーの病院や地域保健サービスセンターの情報を提供し、オンライン予約、電子診療情報作成、オンライン問診など、様々なサービスを提供します。
自分もその機能を試してやってみました。

独身の日(11/11)もう寂しくない

元々中国の11月11日は「光棍節（こうこんせつ）」と呼ばれており、日付の１人を連想させる「１」が並ぶことから一般的に独身の日という意味合いが広まりました。 2009年、そこに目をつけたアリババは、同年11月11日に中国でECサイトの大規模な販促イベントを開催。
今年はちょうど独身の日セール開催の１０年目です。わずか１分間で1000億円、一日５兆円売上達成しました。また記録を更新しました。
なぜこんな大量のデータのやり取りができるでしょうか？サーバーの冷却処理は大丈夫でしょうか？
アリババ自社開発の液浸冷却や浸水空冷をはじめとするグリーンテクノロジーにより、Eコマース取引1万件あたりの電力消費量を2kWhまで低減しました。これにより「天猫ダブルイレブン」のデータセンター全体の消費電力量を昨年から70%削減して20万kWh以上の省電力を実現したそうです。

なぜいつも進化していますか

では、なぜ常に進化していますか？ 政府の協力と技術の発展はもちろんですが、私は失敗を恐れず、チャンスとスピードが優先は最も大きな理由だと思います。
中国IT産業は世界の最先端で走ってるとよく言われていますが、この２０年の発展を振り返ってみると、順調とわ言えないです。例えば、シェア自転車事業の初期段階で、大量遺失や路上放棄と言った社会問題、ネット通販でも消費者損壊事項が数多く発生したなど、様々で問題が発生してしまいました。
「昨日より今日はよくなる」、これは中国でよく言われてる言葉です。あらゆる規制や障害に挑戦しながら、試行錯誤を繰り返して、その結果は現在どんどん便利になってる生活だろう。
その繰り返しの結果で、50代のお母さんはDiDiでタクシーを呼ぶのは常識だと思い、街の豆腐屋さんでもQRコードで決済するのは当たり前なことで、飲食店でマシンでセルフ注文、セルフ会計は普通なことで、携帯さえあれば、なんでもできちゃう生活になってきます。

年末にはまた中国に帰りますが、次の進化、楽しみしています^^

Challenges of working remotely in a Japanese IT Company

リモートワーク カルチャー アドベントカレンダー2019

Hello. This blog article is part of the advent calendar series of blog posts for the year 2019. Click here for the links to the other blog posts.

I am not a big fan of long blog posts and neither am I good at writing long articles so I will try to keep this as short as possible. To be honest, this may probably be my first blog post in English.

Introductions first

My name is Atreya and I work as a software engineer at BBSakura Networks. I am striving to become one of those full-stack engineers (although I am still a long way off from becoming one).

The keyword here is "Remote"

All members of our engineering team work remotely, some work from home (like me), and some work at the office and we are spread out in different locations within Japan.

Being a completely remote team most of our interactions are done textually via Slack. We do have weekly teleconferences etc. but most of the day to day conversations happen almost completely within Slack.

Work Culture

To be honest, I have been using slack for only about a year. Initially, I was excited because I don't have that many emails to check on anymore.

However, it slowly dawned upon me that I couldn't get used to textual communication, especially in a foreign language. I had to read and write Japanese almost all day long to communicate with my colleagues and it was starting to become a big cognitive burden (especially because I have read Kanji all day long, my eyes hurt!)

Switching to English did not help that much because my colleagues took a longer time to respond because they had to first understand what I was talking about.

Communicating using the Japanese language is not the same as using the English language and I do not want to get into the specifics of how they are different. But it suffices to say that the English language, for example, promotes direct speech more than indirect speech which is more frequently used in Japanese. And this only complicates things.

Issues that could probably get resolved within minutes, if I just went to my colleagues' desk and had a small chat, took at least an hour to just get my point across. I am not trying to be negative here or implying that the work culture is bad. On the contrary, since everyone works remotely, all my colleagues are kind enough to answer any stupid questions that I have and I am grateful for that.

I have this habit of asking “why” all the time because I want to know the reason behind certain questions and actions. This becomes very important especially in the context of textual communication as all you have in front of you are the words and not the facial expressions or emotions to back those words. So I make it a point to add emojis to most of the messages I send to add a bit of human touch to them.

And I think it’s important to maintain this work culture where any question, regardless of whether the said question is stupid or not, can be asked freely without being berated for it or being said that the answer to such a question is fundamental knowledge and/or common sense.

The reason may be obvious to the person asking the question but of course, the person asking the question cannot assume that the person who is going to answer the question understands the meaning and purpose of the question.

My closing thoughts

Since most of what I wrote may have sounded a bit negative, I would like to end this post on a positive note.

As human beings, (regardless of whether we are Japanese, American, etc.) we all have different ways of thinking and we should to listen to others and try to understand their way of thinking. The result may be good or bad, right or wrong but we cannot know that unless we discuss it. This is not restricted to just textual communication but all forms of communication. We are not robots after all.

And most importantly, whenever we are conversing online purely through text, we should always be mindful that there is a person who is typing those words and we should be considerate and give careful thought before we send a message to someone.

That's all folks!

DNS暗号化まわりについて雑に調査してみた件（前編）

DNS セキュリティ ネットワーク 技術 アドベントカレンダー2019

こんにちは

冒頭から不穏な画像ですみません。

この記事はちょっと文字が多くて長いので、結論だけ気になる人は最後の方に貼ってある調査結果のグラフあたりから読んでください！

BBSakura Networksの牧です。この記事は BBSakura Networksのアドベントカレンダー 20日目です。

私たちがいつもお世話になっているDNSですが、いまだにそのほとんどの通信が暗号化されていないため、冒頭の画像のようにどのサーバにアクセスしようとしたのかが誰からでもわかる危険性があります。
そのような現状から、近年DNS通信の暗号化手法がいくつか出現しはじめています。

しかし、暗号化と聞くとまず「ちりつもで通信が遅くなるのでは？」とか思いますし、DNSなんて一般ユーザからしたらどうでもいいものを、わざわざ暗号化なんて「めんどくさそう」とか思います。
なので、この調査では - ① DNSに暗号化をかけるとやはり遅くなるのか？ - ② 技術者でなくても簡単にDNSを暗号化できる方法はないか？

について雑に探ってみます！

今日の前編では、「① DNSに暗号化をかけるとやはり遅くなるのか？」について、DNS暗号化で名前解決のレイテンシを測定してみた結果をまとめます。

おことわり事項

  • 冒頭の画像は、実験目的で自分で生成したパケットをスニフィングしたものです。
  • この記事内では特定のサーバに対して大量にパケットを投げつけるような行為がありますが、健全な調査を目的とするものであり、すべてがnonadversarial（敵対を目的としない）のものです。

0. DNSの基本の仕組みを数行で

DNSコンテンツサーバはそのネットワーク内のDNSのボスで、ゾーン情報（そのネットワークにどんなドメインがあるのか）を管理しているサーバです。

一般的に、ユーザ端末（スマホなど）は DNSキャッシュサーバに対してDNSクエリを投げてサーバが持っているキャッシュからそのままDNS応答を得ます。
ですが、キャッシュなのでいつかはサーバから消えます（キャッシュのTTLはキャッシュサーバで任意に設定できる）。

その時にキャッシュサーバは、必要に応じて最新のレコードをコンテンツサーバに取りに行きます。

  • DNSキャッシュサーバ...ここではフルリゾルバ（リカーシブリゾルバ）の意味で使います。
  • DNSコンテンツサーバ...権威サーバとも言います。

1. (前座) DNS暗号化手法にはどんなものがある？

1.1. 冒頭ではしょった説明について

DNSの暗号化には、プライバシ保護を目的としないものと、プライバシ保護を目的とするものがあります。

「プライバシ保護を目的としないもの」は今から20年くらい前の1997年に RFC になっています。これは DNSSEC (RFC2065) です。

一方で、「プライバシ保護を目的とするもの」の方は最近いくつか手法が出てきており、 - DNS over TLS - DNS over DTLS - DNS over HTTPS - DNS over QUIC

などがあります。

冒頭では説明をはしょりましたが、この記事はこちらの「プライバシ保護を目的とするDNS暗号化」についてのものです。とくに DNS over TLS (DoT) について実験調査してみました。

1.2. 暗号化「DNSSEC」の用途

DNSSECは、コンテンツサーバへのDNSクエリに対する応答が 本当にちゃんとしたコンテンツサーバからの応答なのか？というのの検証のために存在します。
なりすましの返答じゃないよな？ということです。

また、暗号化するのはDNSのクエリ／応答の内容ではありません。差出人検証のために使う電子署名に暗号化を使っているよ〜ということなのです。つまり、プライバシの保護を目的としていません。

1.3. 暗号化「DNS over TLS」などの用途

一方で、こちらはプライバシの保護を目的としています。
どんなDNSレコードを問い合わせたのかはわからなくなります。つまり、DNSのクエリ／応答の内容をTLSなどで暗号化しているので、DNS通信の当事者以外は中身を見ることができません。

DNSSECとDNS over TLSはそれぞれ目的が違いますし、互いに独立した別々のメソッドです。なので、どちらが優れているとか劣っているということはなく、目的に合わせてそれぞれを選んだり組み合わせるというのが正しい使い方です。

2. (本題) レイテンシ測定＆比較

2.1. 実験内容＆条件

大雑把な測定です。 - 以下のパブリックな複数のリゾルバに対して、特定のドメイン・IP空間の名前解決を 正引き（ドメインからIPを得る）と逆引き（IPからドメインを得る）の両方で要求して比較しました。 - それぞれ DNS over TLS (DoT) と 従来の暗号化されていない平文(UDP) の両方で問い合わせました。Knot DNSプロジェクト による kdig というdigの拡張版みたいなツールを使いました。 - kdigでのTLS暗号化問い合わせは、毎回TLSハンドシェイクと切断が発生します。今回はこのハンドシェイクも含めたレイテンシ測定をしています。（厳密にいうとexecが走り始めてから応答を受け取るまでの時間を測定端末で測定しているので、測定端末内のオーバヘッドも含まれます） - 今回Wiresharkは見てません😫（pcapファイルが膨大になるので、、） - ハンドシェイクを除いた単純なクエリ時間についてはたぶん平文と一緒だと思って測定しませんでした（実装見たわけじゃないのにそう思う人） - 測定は日本国内のISPに接続された端末から実施しました。 - 確実にキャッシュを持っているときを測定したかったので、一回クエリを投げた後にキャッシュTTL以内に別プロセスで再度問い合わせをかけてそのレイテンシを計測しました

プロバイダ 対応タイプ IPアドレス フィルタリングの有無
Cloudflare DoT, DoH, UDP 1.1.1.1 なし
Google DoT, DoH, UDP 8.8.8.8 malicious domain
Quad9 DoT, DoH, UDP 9.9.9.9 malicious domain

※ malicious domain ... 既知の悪意あるドメインに関する問い合わせには応答しないという意味

2.2. レイテンシ測定結果と感想

2.2.1. レイテンシの表

正引き . . : 逆引き . .
リゾルバ 応答タイプ レイテンシ中央値 : リゾルバ 応答タイプ レイテンシ中央値
Cloudflare DoT 8.0 ms : Cloudflare DoT 91.5 ms
〃 UDP 36.5 ms : 〃 UDP 92.1 ms
Google DoT 87.8 ms : Google DoT 113.7 ms
〃 UDP 79.6 ms : 〃 UDP 117.6 ms
Quad9 DoT 251.7 ms : Quad9 DoT 118.7 ms
〃 UDP 222.1 ms : 〃 UDP 114.6 ms

2.2.2. レイテンシのヒストグラム

青色...DoT、オレンジ色...UDP
横軸...レイテンシ(ms)、縦軸...そのレイテンシで来た応答の数

  • 正引き（Cloudflare, Google, Quad9）

  • 逆引き（Cloudflare, Google, Quad9）

2.2.3. 感想

まず上の結果をみて あれっ？となりました。平文のUDPの方が暗号化のDoTより応答が遅いようにも見えます。。。
（2000クエリくらい連続で同じサーバに投げると10分くらいブロックされてタイムアウト時間内に応答が返ってこなくなったので、何回かやり直した😭🙏）

とはいえ、ロードバランシングされてると思うので、実際に名前解決してくれたサーバが地理的にどのくらい離れているのかとか、その辺にもよるのでなんともいえません。

また、測定した時間帯がバラバラだったりしたので、時間帯による影響もややあるかもしれません。（もしクエリかけたリゾルバがヨーロッパにあったとしたら、ヨーロッパが昼の時間帯にヨーロッパ人のアクセスが多いかもしれない）
（本当になんともいえない）

もしかしたらDoT用のサーバが別経路にあって、そちらがすいていたので応答が早かった、、などあるでしょうか。
正引き逆引きそれぞれだいたい8~14時間くらいかかりました。（クエリのクールダウンタイム含む）

※ DoTは2016年にRFCになったばかりで、DoTの提供はCloudflareが去年2018年に、Googleが今年2019年に開始したばかりです。

3. 各種DNS暗号化手法の違いと特徴

3.1. DNS over TLS

DNS over TLS はRFC7858で標準化されており、RFC2246で標準化されている TLS(Transport Layer Security) を使ったDNS通信の暗号化手法です。TLSは、公開鍵と電子署名を使った暗号化プロトコルです。デフォルトのポートは853番です。

3.2. DNS over DTLS

DNS over DTLS はRFC8094で標準化されており、RFC4347で標準化されている DTLS(Datagram Transport Layer Security) を使ったDNS通信の暗号化手法です。DTLSはTLSみたいなことをデータグラムでも実現できるプロトコルです（TLSがストリーム単位の暗号化であるのに対し、DTLSはデータグラム単位の暗号化）。デフォルトのポートは853番です。

3.3. DNS over HTTPS

DNS over HTTPS はRFC8484で標準化されており、ブラウザやOSを新たに設定する必要のないDNS通信の暗号化手法です（すばらしい！）。Googleは DNS over HTTPS のWebAPIを試験的に公開しています。さらにDNS通信をHTTPSでラッピングするため、外部からはそもそも他のHTTPS通信と区別することができません（DNS通信が流れていることすらわかりません）。デフォルトのポートは通常のHTTPSと同じ443番です。

以下のようにブラウザにURLを打ち込むと、答えがJSONで返ってきます。

https://dns.google.com/resolve?name=www.bbsakura.net&type=A

詳しくは こちら をチェック！

3.4. DNS over QUIC

DNS over QUIC はGoogleが試験的に開発している QUIC(Quick UDP Internet Connections) を使ったDNS通信の暗号化手法です。QUICはトランスポート層プロトコルです。QUIC はIETFのドラフトになっていますが、2019年時点でまだRFCにはなっていません.

3.5. DNSCrypt

DNSCrypt は上記の他のメソッドと同じくクエリのスニフィングやスプーフィングを防止することを目的としていて、DNSCrypt Projectで推進されています。しかし、DNS over TLS とは異なりパケットのパディングがないためパケット長は可変です。他のメソッドと同じようにクエリの完全性は保証しますが、プライバシの保護の観点はありません（パケット長から中身を推測する攻撃手法もある）。こちらも2019年時点でまだ標準化されていません。

まとめ

  • DoTとUDPでレイテンシを比較してみたが、ハンドシェイク含めてもそんなに変わらないかもしれない
  • 調査対象のリゾルバは、どれも2000クエリくらい連続で投げるとその後10分くらいブロックされるconfig入ってる
  • セキュリティ的に一番いいのは、DNSサーバ間を DNSSEC と DoX で暗号化してくれることです
  • 単純に平文DNSのパフォーマンス比較は こちら などにアクセスすれば見ることができます

ふろく

DNS暗号化普及率はどれくらい低い？

WEBでよく使われているHTTPSの普及率は、Googleのブログ によれば、Android, Windows, Macで70%前後（2017年）です。

DNSは 1987年にRFC1035で標準化されましたが、そこから今に到るまで暗号化通信の普及率は低いままです。
APNICのこの地図 を見ると、いにしえのDNSSEC（1997年にRFC2065で標準化）でさえ この記事を書いた時点(2019年末)の世界で普及率わずか 24% です（リンク先では常に値が変動してます）

BBSakura Networksでの働き方

カルチャー リモートワーク アドベントカレンダー2019

はじめに

この記事はBBSakura Networksアドベントカレンダー2019の16日目の記事です。

ブログの内容

おはようございます。

2019年8月1日で設立された、BBSakura Networksで取締役COOをやらせていただいている山口です。

すでに一日目のアドベントカレンダーでチームメンバーの方がリモートワーク前提の会社でのコミュニケーションの現状について記載させて頂いていますが、今日はそんなリモートワーク前提の会社の BBSakura Networks で新しいチームメンバーを迎えるにあたって、どういう方なら一緒にやっていけるか社内に聞いてみたことについても共有したいと思います。

リモートワークを取り入れておられる会社、これからリモートワークの制度を取り入れようとしておられる会社の方、責任者的な役割を持っておられる方たちに、ちょっとでも参考になればと思います〜

BBSakura Networksは比較的多様性のある会社だと思う

多様性というと色々ありますよね。多様性というのは、ただただたくさん種類があるというわけではなくて、一定の傾向を持っているまとまりが、その状態を維持しつつ活動を続けている状態です。

もともとは生物学や環境学てきな用語の生物多様性から来ているのかなと思いますが、環境省さんによると「生きものたちの豊かな個性とつながりのこと。」なので、ビジネス的の感じだと、個性的でありつつ連携をして目的を達成するために各自で変化と努力をし続ける状態ですかね。

ところで、BBSakura Networksですが、社員は東京に2拠点、大阪、北海道、（あとは各自の自宅）など拠点はあるけれども、同時にリモートワークもOKになっているので、拠点には必ずしもこだわらない働き方をしていると思っています。

さくらインターネットとソフトバンクグループのBBIXのジョイント・ベンチャーということもあり、社員も両方から来ています。ですので、元々やっていた仕事も、固定キャリア、ISP、クラウド事業者、IOT、MNOなど様々なところから集まってきています。

国籍は現在は日本、中国、インドですがこれからたくさん増えていきそうです。

こういった状態だと当然メンバー間の価値観も違いますし、同じ事柄についてどう考えるかについても全く違います。

しかし価値観を揃える必要性は全くないと考えていて、むしろ違いを生かしてそれぞれができることを最大限にやっていただけるように心理的安全性に配慮しつつ努力したいですね。

※　心理的安全性で調べていたらめちゃくちゃしっかり書かれているQiitaを見つけたので興味のある方はどうぞ！

設立からまだ4ヶ月目ですが、そろそろ「アレアレ？？なんか今まで普通だと思っていたこと何だけれども、お互いに話があわないぞ？？」みたいな事も出てきていて、とても良いと思っています。

ぜひとも、「どっちかに寄せる〜」とか「それぞれの範囲で」ではなくて話をして理解し合っていきたです。

働き方

リモートワーク前提だと、どうしてもツールが多くなってしまうので、フロー情報については、Slackに連携をするなどして基本的には直接そのツールに触らなくても良いようにしたいと思っています。

出勤・退勤したタイミングもわからない（これはチームメンバーを守る立場の管理職としては良くない）ので、以前はタイムカードに出勤退勤を書いてもらっていたのですが、これがちょっとした手間でメンドイので、Slackに専用のコマンドを作ってSlackに書き込みをすれば、タイムカードに自動的に入力され、チャンネルにも出勤が記載されるので楽になったと実感できた良いものかなと思います。ちょっとした手間だからこそ無くせるもんなら無くしていきましょう。

　基本的には顔を突き合わせるメンバーがあまりいない、いても特定の少数の方のみという環境なので、拠点メンバーの方が対面で良いコミュニケーションが取れているかというと実際にはそうでもないです。

　他の人と音声や顔が見えるコミュニケーションを取るためには、基本的にG suite のmeetやSlack コール などを使っています。

このあたりの使い分けは、時間をきめて会議をする時にはmeet、ふとなにか気になって話がしたくなった時にはSlackコールみたいな感じなのかな？

さてさて新しいメンバーを募集したいんだけれども。。。

　リモートワークできる！やりたい！と言って新しいメンバーに参加いただいたとしても、実際にはじめてみると、どういうタイミングだったかやその時のチームの構成等などによって、チームから支えるべきところが異なっていそうという気がします。

状態や状況は常に変化し続けているので、その都度ごとにしっかりやっていかないといけないですね。

リモートワーク適正・適性

チームメンバーの採用をするにあたって、どんな素養が必要なのかチームメンバーに聞いてみました。

言語的なスキルやぼくらがやろうとしていることの大前提としてネットワークについてのなどが上がってきたのですが、チーム自体がリモートワーク前提なので「リモートワークが問題ないこと」、適正・適性があることということが複数のメンバーから挙げられました。

リモートワーク適正・適性

「適正」とは、「適当で正しいこと」。例文として「適正な手段」「評価が適正を欠く」

「適性」とは、「ある事に適している性質や能力。また、そのような素質・性格」

具体的な項目を聞いてみると

  • 人の声／表情が見えなくても不安にならない
  • 不安になったとしてもちゃんと伝えたいことを伝える
  • 気になったことは聞ける
  • 複数の意味が含まれる場合は聞き返せる
  • 文字だけではなく、他のコミュニケーション手段をもっている

とのことでした、リモートワークは比較的新しい働き方かなとも思います。

上記のことはインターネットを利用する際のリテラシに少し付け加えたものに近いですね。

表情が見えなくても不安にならない人もいます。表情が見えないと不安になるタイプの人もいます。不安になるタイプの方は、そうでない人に比べて、普段からストレスが発生してしまっているかもしれないので、適性はどちらかというと無いということになるかもしれませんが、自分がそういうタイプであれば、不安になったことを伝えることが大切ですし、チームメンバーが不安を伝えられるような雰囲気を常に意識するということも必要ですね。

リモートワーク文化醸成にむけて

Slackなどのコミュニケーションツールを使うと、今までのやり取りとは異なって、非同期でやり取りをするようになり、あとから辿れるようになるため、対面のフロー情報のコミュニケーションだけでは表面化してこなかったコミュニケーションの課題に向き合う必要が出てきます。これらの課題に向き合いリモートワークを円滑にするためには、必要になるシステムを使いこなせる能力、使いこなすための努力を続ける力ももちろん、広い意味でリモートワークの文化を醸成し理解しあうということも必要かもしれません。

会社側からの必要なフォローはもちろんですが、下記のようなことを相互に自発的にできるようになるとより快適にしていけるのではないでしょうか？

対面コミュニケーションが取れなくても過度なストレスにしないようにする

→ ネガティブな思考に向かいそうになったら対応できる

自律して仕事をする

→ こまかく指示受けなくても大丈夫！

慮ることができる　（悪い意味での忖度は不要だよ！）

→ リモートの人もいれば、集まって仕事をしている人もいるよ

リモートワークの良いところに目を向ける

→ 課題もたくさんありますが、良いところをみましょう！

だいぶリモートワークの話になってしまいました。僕自身は会社を引っ張っていく立場になって、最近思うのは会社やチームは、まるでいきもののようだなということです。

いきものには心臓の役割をもっている細胞チームも、肝臓のように必要な物質を生産する細胞チームなどもたくさんありますよね。それらに何らかの外的刺激があった時に普段どおりの自分のチームだけが健康で万全な仕事をしていたとしても、体全体でみるとよりよくない状態になってしまうというのはよくあることです。（詳しくははたらく細胞１５話でも見てくださいｗ）

会社組織もそれを構成していると自分自身どちらもヘルシーな状態にたもつ為にはどうしていけばよいか、できたばかりのBBSakura Networks ではまだまだいろいろな課題があります。そういった課題をチーム全体が自分ごととして解決していき続けられるような環境にしていきたいですね。

とりとめのない話になってしまいましたが。

こんな感じで楽しくやっていて、チームメンバーを募集しております！ご興味のある方はぜひお話し聞いてください〜

no ramen, no life?

インターネット カルチャー アドベントカレンダー2019

title: "no ramen, no life?" date: 2019-12-15T22:08:24+0900

draft: false

なんでまたRamen?

この記事はBBSakuraNetworks Advent Calendar 2019のものです。これまで非常に高尚な内容で推移してきましたが、いきなり私がレベルを下げたいと思います^^;

なんでまた"no ramen, no life"なのか？「えっ福智さん、そんなにラーメン好きだっけ？」と言う声が聞こえそうです。はい確かに私はラーメンよりワインですし最近はワインより日本酒だったりもします。

「じゃー何でラーメン？」　これはCloudFlareのTom Pasekaさんの影響が大きいです。彼と香港で食べたButaoのラーメンが美味しかった！それ以降、彼と海外のイベントで会うとラーメンを食べるようになりました。いつしかその「麺会」はRamen BoFとなりFacebookページに発展していきました(現在メンバー数146人！)。BBIXのモットーは"no peering, no internet"なのは前回お話しましたが、それに掛けてここでのモットーは"no ramen, no life"としました。今ではTomが悪ノリしてロゴマークは作るはステッカーにするは挙げ句の果てにはバッチまで作る！もっとノリが良すぎるのがBBIXというか私でついにBBIXノベルティーをカップラーメンのラッピングで"no peering, no internet"と"no ramen, no life"の両方を載せるという馬鹿技に走ってしまいました^^;　ただ海外のお客さんの評判はめちゃ高くAwesome!の連続です。私も調子にのって"My company slogan is "no peering, no internet" but my life slogan is "no ramen, no life!"というとウケがいいです。英語も日本語もリズムが大事なのでそう意味でも良いと思いますがね^^;

それ以降、海外出張をするたびほぼ毎回現地でラーメンを食し、FBにno ramen, no life in XXXと上げています。過去49件の海外のラーメン屋さんを訪れていますが今回はその中での「海外ラーメンベスト５」をご紹介したいと思います。

(Ramen BoFの様子)

(Tom Pasekaさんと"no ramen, no life")

海外ラーメン勝手にランキング

No.5 Menya Ramen Denver (https://www.menyacolorado.com/)

このお店はNANOG73 inDenverの時に寄ったラーメン屋さん。アメリカに限らず海外のラーメン屋さんはスープはそこそこですが麺がちゃんと作れません。何でも材料の仕入れが難しく日本のような製麺ができないとか。その中においてこのMenyaさんのラーメンは麺も及第点。スープもおいしい。あとDenverという街がお気に入りというのもTop５入りした要因かも^^;

No.4 Kanadaya London (https://www.kanada-ya.com/)

金田屋という元々福岡の行橋にあったラーメン屋のロンドン店。大英博物館の近くにありいつも行列が外まで伸びています。この近くには一風堂のロンドン店もありロンドンではラーメン銀座かもです。あっさりしたスープながらしっかりコクもある。博多で人気な理由が分かりますし、ロンドンっ子を虜にしているわけですね。

No.3 Butao in Causeway Bay HongKong (https://www.butaoramen.com/)

ここは前出のCloudflareのTomの紹介で行ったお店です。Peering Asia2.0 in Hong KongでのRamenBoFもここで行いました。渋谷にあるラーメン凪 豚王が本店であり、香港はその分家のような存在だと思います。渋谷本店と香港の店舗の比較をしているWebがありましたので載せておきますね。( https://gigazine.net/news/20140926-butao-ramen/ )私の感覚もこのWebと同じく日本人には少し濃い目でRichな味がします。ただTomはいつもここでMore Richにして物凄くこってりを追求します。また彼に言わせると香港でもCauseway BayよりCentralのお店の方が美味しいらしいです。私にはその違いはあまり分かりませんでしたが。。。

No.2 Kaminari Tonkotsu RAMEN Mexico City (https://www.facebook.com/Kaminaritonkotsu/)

先日行ったばかりのお店です。店のたたずまいも「大丈夫かな？」と言う感じでしたがひとつひとつ丁寧に作られていて美味しかったです。麺も期待以上の出来であったと思いますし、なぜかバランスがよかったと言う印象です。

No.1 Kodawari Yokocho Ramen in Paris (https://www.kodawari-ramen.com/)

私が何と言っても絶対にNo.1にあげるお店がKodawari Yokocho Ramanのパリにあるお店です。ルーブル美術館の近くにあるお店ですがかなり有名らしくいつも行列が出来ているようです。このお店のいいところは何と言っても麺がおいしい。おそらく海外で食べるラーメンで麺が一番おいしい。何でも日本で修行した確かバングラデシュのラーメンシェフがこのラーメン屋を作るのに製麺機まで購入しパリに運び、この店の地下室で「こだわりの麺」を作っているそうです。内装も昭和時代を思わせるイメージで新横浜・ラーメン博物館と同じテイストに仕上げるという「こだわり」です。なのでお店の名前も"Kodawari"なんでしょうね。パリにいって日本食が恋しくなったら絶対におすすめのラーメン屋さんです。

番外編 Yui Dubai (https://selectshopframe.com/pages/about-yui)

番外編で取り上げたいのがYui Dubai。なんと中東のDubaiにあるラーメンが食べれるお店。といっても流石にイスラム国家ですから"Tonkotsu"なんてありません。ただそれ抜きで美味しいラーメンを一生懸命考えて作っていると思います。味のトータル点数は流石に上位のお店を凌駕することはできませんが、中東にいってラーメンが恋しくなったら行く価値はあると思います。

まとめ

この活動？を通じていつも思うことなんですが、中国生まれのラーメンですが間違いなく日本育ち。そして世界中のPeering GuysがRamen大好き。RamenBofで皆んなで食べるときは本当にいい笑顔。次はHawaiiのPTCでのRamenBofかな？「情報革命で人々を幸せに」ならぬ「ラーメンで人々を幸せに！」。。。なんの会社かわからなくなってきました^^;

セキュアなリバースプロキシの作り方

技術 アドベントカレンダー2019

こんにちは

この記事は BBSakura Networksのアドベントカレンダー 14日目です。

在宅などのリモートでの働き方が増えてくると、困ることの一つに社内のシステムへのアクセスをどうやってセキュアに行うかがあります。クラウドのサービスであれば2段階認証などが提供されていますが、私のようなエンジニアが社内のサーバに立てたツール等は、社内のLANからのみアクセス許可することでセキュリティを保ってる場合も多いと思います。このようなシステムへのリモートアクセスをセキュアにするために、Oauth2による認証連携とクライアント証明書によるアクセス制限が行えるリバースプロキシ の立て方を紹介したいと思います。同様なことは、検索してくだくといろ色々なサイト紹介されていることも多いと思いますが自分用のメモもかねて記事にしたいと思います!

環境

リバースプロキシは ubuntu 上でdockerを使って構築しています。

構築手順

0. 概略

Internet --- reverseproxy(https://reverseproxy.example.co.jp) --- 社内システム(http://10.10.10.10)

oaut2_proxy と連携する　oauth2 provider は、oauth2_proxy の default　でもある google を使用しています。

1. docker/docker-composeのインストール

 sudo apt install curl
 curl -fsSL get.docker.com | sudo sh
 sudo curl -L "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
 sudo chmod +x /usr/local/bin/docker-compose

2. 用意したファイルとディレクトリ

reverseproxy/
|-- CA
|-- default.conf
|-- docker-compose.yml
`-- Dockerfile

3. ディレクトリ作成

mkdir reverseproxy
mkdir reverseproxy/CA

4. docker-compose.yml

docker-compose.yml は下記の内容でファイルを作成してくだい。

version: '3'
services:
  reverseproxy:
    build: "."
    image: "reverseproxy"
    container_name: "reverseproxy"
    ports:
      - "443:443"
    volumes:
      - ./default.conf:/etc/nginx/conf.d/default.conf
      - /etc/letsencrypt/live/reverseproxy.example.co.jp/privkey.pem:/etc/ssl/private/server.key
      - /etc/letsencrypt/live/reverseproxy.example.co.jp/fullchain.pem:/etc/ssl/certs/server.crt
      - ./CA:/etc/ssl/demoCA
    depends_on:
      - oauth2_proxy
  oauth2_proxy:
    image: "quay.io/pusher/oauth2_proxy:v3.1.0"
    container_name: "oauth2_proxy"
    command: >
      --http-address=0.0.0.0:4180
      --redirect-url=https://reverseproxy.example.co.jp/oauth2/callback
      --cookie-secret=example.co.jp
      --client-id=XXXXXXXXXXXX.apps.googleusercontent.com
      --client-secret=XXXXXXXXXXXX
      --upstream=http://10.10.10.10/
      --email-domain=example.co.jp

reverseproxy のサーバ証明書は、Let's Encrypt で作成したののをdockerのnginxでも使用しています。
Google のクライアントキーとシークレットは Google Developers Console から取得しています。

5. Dockerfile

クライアント証明書を作成するために　opensssl をインストールした nginx のイメージを作成するための Dockerfile です。

FROM nginx

RUN apt update && apt install openssl

EXPOSE 443
CMD ["nginx", "-g", "daemon off;"]

6. default.conf

nginx の設定ファイルです。初回立ち上げ時は、CA局の証明書がないため ssl_client_certificate と sl_verify_client はコメントにしておきます。

server {
    listen 443 ssl;
    server_name  localhost;
    server_name reverseproxy.example.co.jp;

    ssl_certificate     /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc//ssl/private/server.key;

    #ssl_client_certificate /etc/ssl/demoCA/ca.crt;
    #ssl_verify_client on;

    location / {
        proxy_pass http://oauth2_proxy:4180;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

7. docker 立ち上げ

sudo docker-compose build reverseproxy
sudo docker-compose up -d

8. クライアント証明書作成

問題なく docker のコンテナが起動したら、次はクライアント証明書を作成します

8.1 クライアント証明書作成

reverseproxy コンテナに bash でアクセスし、openssl を使ってクライアント証明書を作成します。

sudo docker-compose exec reverseproxy bash

以下は、reverseproxy コンテナの中で実行します。

CA局の証明書作成
cd /etc/ssl/demoCA
openssl genrsa -out ca.key 2048
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt -subj "/C=JP/ST=Tokyo/L=Shinjuku-ku/O=Example/OU=Development/CN=reverseproxy.example.co.jp/emailAddress=admin@example.co.jp"

cd /etc/ssl
openssl ca -name CA_default -gencrl -keyfile ./demoCA/ca.key -cert ./demoCA/ca.crt -out ./demoCA/ca.crl -crldays 3650

touch demoCA/index.txt
echo '01' > demoCA/crlnumber

CA局 の Common Name(CN) には、リバースプロキシの FQDN を指定します。

クライアント証明書作成
cd /etc/ssl
openssl genrsa -out ./demoCA/user01.key 2048
openssl req -new -key ./demoCA/user01.key -out ./demoCA/user01.csr -subj "/C=JP/ST=Tokyo/L=Shinjuku-ku/O=Example/OU=Development/CN=user01/emailAddress=admin@example.co.jp"
openssl x509 -req -days 365 -in ./demoCA/user01.csr -CA ./demoCA/ca.crt -CAkey ./demoCA/ca.key -CAcreateserial -CAserial ./demoCA/ca.seq -out ./demoCA/user01.crt

クライアント証明書 の Common Name(CN) には、ユーザ名(上記例では user01 )を指定します。 作成された証明書を PKCS12 形式に変更します。

openssl pkcs12 -export -clcerts -in ./demoCA/user01.crt -inkey ./demoCA/user01.key -out ./demoCA/user01.p12v
exit

コンテナ中での作業はここまでで、'./reverseproxy/CA/user01.p12' のファイルを Windows や　Mac にインストールすればクライアント側の準備は完了です。

NGINXの再起動

サーバ側の証明書も作成し終えたので、最初にコメントした NGINX の ssl_client関連のコンフィグのコメントを外し, コンテナを再起動します。

reverseproxy/default.conf を編集

ssl_client_certificate /etc/ssl/demoCA/ca.crt;
ssl_verify_client on;
````

コンテナの再起動

sudo docker-compose restart reverseproxy ````

以上です。

BBSakura Networks Blogで使っている技術

技術ブログ 技術 アドベントカレンダー2019

※この記事の内容は古くなっております。現在は はてなブログ for DevBlog を使っています。

こんにちは。BBSakura Networksの日下部(@higebu)です。 この記事はBBSakura Networkのアドベントカレンダー 11日目として書きました。

昨日は佐々木社長による Peeringの世界とインターネット でした。

今更ですが、BBSakura Networks Blogを作ったので、特にすごい技術を使っているわけではないのですが、使っている技術について簡単に紹介したいと思います。

ちなみに、作った理由は、個人のSNSなどのアカウントと仕事を結びつけたくなかったり、そもそもブログを書いていないような人でもアドベントカレンダーに参加しやすくするためです。

Hugo

開発運用しているプロダクトではGoを使っていることが多いのと、使っている人が多いので、これにしました。 今確認したところGitHubのスター数が40036でした。

テーマはシンプルなものを探していたところ、 inkblotty が良さそうだったので、これをベースにロゴなどいくつかの修正をしたものを使っています。 余裕があれば独自のデザインにしたいという気持ちはあります。

コンテンツはMarkdownで書かなかればならず、gitも使えないといけないですが、弊社では社長もMarkdownで記事を書き、gitコマンドで記事を公開しています。

GitHub Pages/GitHub Actions

このブログはURLでわかる通り、 GitHub Pages でホストしています。 また、公開は GitHub Actions で自動化しています。 ブランチとしてはMarkdownで書いた記事や画像ファイルのための source ブランチと、Hugoによって生成されたコンテンツのための master ブランチがあり、 master ブランチのコンテンツはGitHub Actionsで自動で更新されます。 実際のworkflowは下記のようになっています。

name: github pages

on:
  push:
    branches:
    - source

jobs:
  build-deploy:
    runs-on: ubuntu-18.04
    steps:
    - uses: actions/checkout@v1
      with:
        submodules: true

    - name: Setup Hugo
      uses: peaceiris/actions-hugo@v2
      with:
        hugo-version: '0.60.1'
        extended: true

    - name: Build
      run: hugo --minify

    - name: Deploy
      uses: peaceiris/actions-gh-pages@v2
      env:
        ACTIONS_DEPLOY_KEY: ${{ secrets.ACTIONS_DEPLOY_KEY }}
        PUBLISH_BRANCH: master
        PUBLISH_DIR: ./public

見て分かる通り、 https://github.com/peaceiris/actions-hugo と peaceiris/actions-gh-pages を使っているだけであり、非常にシンプルです。 これらのActionを開発してくれている、 @peaceiris さんには大変感謝しております。 Actionの使い方についての解説はご本人による解説が GitHub Actions による GitHub Pages への自動デプロイ にありますので、割愛します。

以上です。