2019/11/09 OSC 2019 Fukuoka & Rakuten Technology Conference 2019 @ Fukuoka 参加メモ

# はじめに
セッションを聞きながら書いていた、個人的メモです。
何かを思い出すきっかけになればと、一応公開しておきます。


# ● OSC Fukuoka 2019 
[オープンソースカンファレンス 2019 Fukuoka](https://www.ospn.jp/osc2019-fukuoka/)
Twitter ハッシュタグ: #osc19fk

会場はたくさん人がいたが、やはり九産大ということもあって大学生も多かった。
ただ、Kubernetes などの絶対に単語も聞いたことないだろうというセッションは、社会人が多かった印象。

# 1. OpenSDS
> 面白そうだと思って聞きに行ったが、参加者がほぼほぼ大学生で、講師も大学教授だったため、「OSS とは」 の話が全体の9割を占めていて少し残念。

* ストレージはあるものを使って、割付けて使う
* 今までは、ストレージの種類によってそれぞれ別のコンソールで管理する必要があったが、集中管理できる

<br>

# 2. 自宅サーバーを始めてみよう！
> 今はクラウドで簡単にサーバの環境が用意できてしまうが、あえて物理的に自分でサーバを立てることによって
、もっと下のレイヤの勉強やセキュリティについて学びましょうといった内容。
> 実際にサーバを立てると、中国などから 22 ポートに攻撃をバンバン受けているのを見て怖っと思った。

* 自宅サーバを始めるには、GlobalIP を割り当てる ISP と契約する必要がある
* CATV は　PriveteIP を割り当てる ⇨ 外部からアクセスできない
* マシンは RasPi とか
* 自宅サーバのメールサーバから Gmail に送ると大概、迷惑メールに判定される
    * おそらく、メール本文まで見て、判定をしている
    * コンプライアンスは大丈夫？

## 自宅サーバーの公開のやり方
1. WAN から、LAN 側の IP へのポート転送
    - いくつも設定するのが面倒なら、DMZ で一括転送
1. SSH は、WAN(10022) → LAN(22) などに変更
    - 完全なセキュリティではない
1. ポート転送の設定
    - 静的 IP マスカレード
    - 静的 NAT
    - CentOS8 で nftables が導入された
1. ホスト名でアクセスできるように、MyDNS.jp で IP アドレスの通知
1. ホスト名と IP アドレスの確認
1. たいてい、構築したサーバに自宅の LAN からアクセスしようとしてもできない
    - WAN IP -> LAN IP -> WAN IP ができない(ヘアピン NAT)

## 構築ができたら
* 構築のドキュメントを残す
* サーバの監視をする
* データのバックアップをする
    - RasPi は安いが、やっぱり壊れる
* 自宅ラックサーバは、IKEA の LACK がちょうどすっぽりハマる
* /var/log/secure の内容を確認
    - fail2ban などのソフトを活用
    - 不審な IP アドレスは、[IP広場](https://www.iphiroba.jp/ip.php) で検索
    - [脆弱性情報](https://www.jpcert.or.jp/)

<br>

# 3. cybozu.com を支える技術
> サイボウズは愛媛で創業しサービスの成長と共に会社も成長し、今は全国に開発拠点がある。
> 会社として、自分で思いついて作ったものは、OSS としてどんどん公開していいよと言う規定になったらしい。
> 普通の会社では、業務時間内に作ったものの著作権は会社に帰属するが、サイボウズでは逆に基本的に公開 OK で、指定したもの（重要なロジックなど？）は公開 NG を指定するようにポリシーを変えたらしい。

* cybozu.com のライセンス数：130万人 + 34000社
* 全てインフラを自前でやっている
    - AWS などのパブリッククラウドを使っていない

1. サービスの画面をリッチにした結果、巨大な JavaScript になった
1. メンテナンスが大変なため、Google Closure Library を使用している

## サイボウズが開発している OSS
### ytmacds
* [GitHub](https://github.com/cybozu/yrmcds)
* セッション情報を管理
    - いちいちセッションの認証をしていると大変だから、そこをなんとかする
    - webcached をもともと使用していたが、落ちるとデータが消えてしまう
    - セッション情報をキャッシュしつつ、他のサーバにレプリケーションして再起動した時にデータを再取得することができる
    - webcached と完全互換

### WalB
* HDD が記録する、デバイスドライバのレベルでデータのバックアップをする
* Linux カーネル が HDD に書き込む直前にデータをコピーしている

## 会社の著作物に関して
* 業務時間に作成したものは会社の著作物
    - .bashrc .vimrc も会社のもの？ -> それはおかしいよね
    - デフォルトを、OSS で公開して良いものになった
    - 公開してはいけないものを会社で指定するようになった
    - [Cybozu のポリシー](https://cybozu-oss-policy.readthedocs.io/ja/latest/)

<br>

# 4. PostgreSQL 安定稼動のためのヒント
> 正直、よく分からなかった。

* EDB Postgres Platform
    - 1 秒毎に、どのセッションでどんな SQL が発行されたか記録される

## 早期解決するためのヒント
* DB の性能が出なくなった時に、調査するため、平常時のデータを採取しておく

<br>

# 5. Kubernetes が”クラウドにおけるLinux”と表現される理由について、真面目に考察
> Docker のコンテナ技術が使われる理由などをとても丁寧に話してもらえた。
> k8s が、"クラウドにおける Linux" は誰か有名な人の言葉らしい。
> Linux や、k8s は企業などがこぞって周辺のエコシステムを開発しているらしく、これからも成長していくだろうと。

## コンテナ、k8s のおさらい
* 一つのサーバにいくつもアプリケーションを動かすことはしない
    - リソースの割り当て問題
    - サーバが落ちた時の影響範囲
* アプリさえ動けばいいのに、仮想マシンが増えるのはコスパが悪い
* Docker では、サーバ同士でコンテナを管理することはできない
* 複数サーバを一つの集合体（クラスタ）として管理するのが、k8s

## クラウド界の Linux である k8s
### ライセンス
||Linux|k8s|
|---|---|---|
|OSS|サーバOS|コンテナオーケストレーション|
|コミュニティ|Linux Foundation|Cloud Native Computing Foundation|

---
### ポータビリティ
どこでも動く

* 物理
* 仮想
* クラウド

---
### エコシステム
* ディストリビューション
* プラグインによるコア機能拡張
* パッケージ管理による機能拡張

---
### 金のなる木
* エンタープライズベンダーは、自社のプロダクトやサービスに採用
* HW の対応、SW の対応、クラウドの対応

---
### 縁の下の力持ち
* ICT インフラ
* k8s の上で動くアプリにこそ価値がある

参考：[ITの基本から押さえるコンテナ入門](https://news.mynavi.jp/series/zerocontena)

<br>

# ● Rakuten Technology Conference
[Rakuten Technology Conference 2019 @ Fukuoka](https://rakuten-tech-fukuoka.connpass.com/event/148597/)
Twitter ハッシュタグ: #rtechfukuoka
OSC Fukuoka に参加してから移動したため、ちゃんと聞けたのはメルカリのセッションだけだった。
ちょっとしか聞いていないがさすが楽天、外国人社員が多く、ちょっとだけ聞いたセッションも英語だった。
懇親会で聞いた話でも、やはり外国人が多いためコミュニーケーションが大変らしい。


# 1. マイクロサービス開発チームの変遷と挑戦
> メリカリはもともと、PHP で書かれたモノリシックなシステムだったが、サービスの成長と共にサーバサイドを golang に書き換え、マイクロサービスアーキテクチャにシフト中。
> 巨大なサービスをメンテする時に、開発スピードを落とさず、どうやってマイクロサービスアーキテクチャに置き換えていくのかのノウハウなどを話してくれた。
> ユーザのアクションごとにドメインを区切り、その中でサービス毎に少人数のチームを組んで開発を行なっている。
> メルカリの開発者ブログが面白そうだから今後、チェックしていこうと思った。

## メルカリが目指すエンジニア組織
* エンジニアは今、400 人くらい
    -　急激に人数が増えて、生産性が落ちた
* PM/EM/TL 体制の導入
    - EM: エンジニアのポテンシャルを最大化
    - TL: エンジニア
* チーム編成
    - 6~10 人の少人数
    - 開発と運用を一緒にやる
    - フィードバックしながら開発

## 福岡開発チーム
* CS との距離感おを生かしたプロダクト開発
    - クロスファンクショナルチーム
* 機動性の高い多能工チームとして特定ドメインを担う
    - 専門領域を作らず、組織に求められることをする

## マイクロサービス開発のプラクティス
### 過去
* サービス開発時は、PHP の Monolithic なアプリだった
* 1000 人規模で開発
    - 開発、意思決定のスピードが落ちる

### どうやって、マイクロサービス化したのか
* ユーザのアクションによってドメイン(出品、購入)を分割し、ドメイン毎に開発
* 各ドメインチームは最良・責任をもつ
    - 機能開発、運用
* 技術スタック
    - docker, k8s
    - GCP
    - circleci
    - golang
        - バックエンドの開発言語
    - terraform  etc...
* DB
    - 各サービス毎に DB をもつ
        - Cloud Spanner
        - Cloud SQL(MySQL)
    - 参考：[マイクロサービスにおける決済トランザクション管理
](https://tech.mercari.com/entry/2019/06/07/155849)
* CI/CD
    - Spinnaker
    - CircleCI
        - GitHub に push すると、Docker image が作成される
* Monitoring
    - Datadog
    - PagerDuty
        - Datadog で設定したアラートがトリガーされると、oncall 担当者に通知
* SLI/SLO
    - 各サービスで SLO を設定し、Datadog 上で SLI を確認
    - SLO を下回ると、改善するまで開発をすることができない
* ローカル開発環境
    - 依存している他のサービスには、Telepresence をしようしてアクセス可能　
* その他
    - gRPC/Protocol Buffer
        - サービス間は、gRPC で通信

### マイクロサービスのマイグレーション戦略
* API Gateway をプロキシとして、様子を見ながらマイクロサービスにリクエストを流す
* DB は新環境と旧環境に W write して、徐々にサービスを切り出していく