CloudNativeDaysTokyo 2019 参加レポート

## Report

### [Day 1 Keynote]

Time: 10:00 - 12:00
感想: 国境を越えてコラボレーションすること。多種多様な背景を持つ人々が 1 つのプロダクトに対して手を加えることにより、洗練された完成度をもたらす。

Memo:

-   立ち見出てる
-   クラウドネイティブとは、スケーラブルなアプリケーションの構築と実行を行う組織の力を強化するもの

---

#### Openning

-   参加者のうち 8 割強は開発環境にクラウドネイティブ技術を適用している
-   K8s アップルストリームトレーニングの資料を公開していく予定
-   日本企業ではアカツキ, CreationLine inc, モビンギ が CNCF に参加している

#### Collaboration Without Boundaries(OpenStack Foundation)

Speaker:Mark Collier
-   国境を越えてコラボレーションすること

#### Performing Infrastructure Migrations at Scale(Airbnb)

Speaker:Melanie Cebula

1. Cascading Migrations
2. Simultaneous Migrations
3. Sequenced Migrations
4. Prioritized Migrations

#### The 10 new rules of open source infrastructure(Canonical)

Speaker:Doug Davis

-   Ubuntu を作った会社
   
1. Consume unmodified upstream.
  - 修正されていないコードを使う
  - upstream をそのまま使用する
1. Infrastructure-is-a-Product
    - インフラは製品である
1. Automate for day 1826
    - 5 年
1. Run at capacity on-prem. Use public cloud for overflow.
1. Upgrade, don't backport.
1. Workload placement matters.
    - ワークロードをどこに置くか
1. Plan for transition.
    - transition に備えて計画・設計をする k8s で完結ではない
1. Security should not be specia.
    - セキュリティは特別なことではなくて、最初から作りこんでいく。後付けではない
1. Embrace shiny objects.
    - 新しいことはどんどん取り込む
1. Be edgy, go Micro!
    - エッジになりましょう、マイクロになりましょう
    - `$ snap install microk8s -classic`

#### Demand Less Choices!(IBM)

Speaker:Doug Davis

-   Splitting up the monolith
-   Faster start-up times
-   Finer-grained management
-   Better resource utilization / reduced costs
    ・・・

1. Knative
    - コードに集中することができる
    - PaaS ベースと同じ

1. Demo

---

### Re-architecturing of Microservices / 今からでも遅くない！アプリケーションエンジニアが知っておきたい、Docker コンテナの基礎知識

Speaker: Kohei Ota
Slide: https://speakerdeck.com/inductor/the-basic-of-docker-container-for-developers
感想: 久しぶりに基本に立ち返ったかのようなセッションだった

Memo:

5 分前到着だと遅かったのか立ち見に。予約しているか確認しないのか？！

### Kubernetes を拡張して日々のオペレーションを自動化する

Time: 13:30 - 14:10
Speaker:Aya (Igarashi) Ozawa
Slide: https://speakerdeck.com/ladicle/kuberneteswokuo-zhang-siteri-falseoperesiyonwozi-dong-hua-suru
感想: CRD 触れたことなかったから・・・難しいよ！

Memo:

-   Platform Style Automation Makes your System Robust
  1. Testability
  1. Observability
  1. Maintainerbility

-   基盤を作る基盤として k8s は優れている
-   k8s が何をどこまで保証しているか
    -   CRD と Reconciler
-   Kubernetes 本体は良いサンプルコード(Go lang)
-   SDK(controller-runtime) を活用しましょう

-   Maintenance

    -   Event Recorder
    -   Operator Metrics
        -   メトリクスはプロメテウス形式で出力される

-   まとめ
    -   システムの成長に対応するため、自動化が必要
    -   Reliabitity , Scalability, Maintenancebility

---

### k8s 上のアプリケーション向け Secure Service Mesh を A10 でつくる(A10 ネットワークス)

Time: 14:30 - 15:10
Speaker: 石塚 健太郎
Slide: https://www.slideshare.net/KentaroIshizuka/20190722-cndt-osdtishizukar1
感想:スポンサーセッションはどうも製品のプロモーション色が強くて・・・

Memo:

-   サービスメッシュといえば Istio, Envoy だが、A10 でつくるとどうなるかと。
    -   Istio, Envoy を使わなくても便利
-   主力製品が Thunder という Firewall

-   Harmony Controller
-   Lightning ADC(Application Delivery Controller)のご紹介
    -   自足なアプリケーション配信に適している
    -   マルチクラウドにおける一元管理
    -   アプリケーショントラッフィックの可視化とアナリティクス

---

### Cloud Native に立ち向かう JVM ユーザー必見。Kubernetes で Java/JVM アプリを動かすための実践的ノウハウ集

Time: 15:40 - 16:20
Speaker: 早川 博
Slide: https://speakerdeck.com/hhiroshell/jvm-on-kubernetes
感想: 今のプロジェクトの自分の立場にちょうどマッチする内容でかなり面白かった。暖機運転とか jvm パラメータとか後々使うことになるだろう。ありがたや。

Memo:

- `-JVM` とコンテナで動かす場合、注意が必要な点 
  1. JVM レイヤー上での可搬性
  1. 従来アプリサーバはJVM 上で複数のアプリを動かす想定だった

-   JVM on k8s ノウハウ集
    1. ローカル開発

        1. Skafford + Jib

            1. Jib
                - Dockerfile を書かなくても良くなる
                - Dockerfile のベストプラクティスを知らなくても高品質のコンテナが作れる
                - `jvmFlags : jvmに与えるオプション`

            1. Skaffold
                - 面倒な Build, Push, Deploy を自動化
                - build(docker build), Push(docker, push), Deploy(kubectl apply)
                - 開発 k8s クラスターまで自動デプロイさせる

            1. Jib を使うと Build と Push が Jib になる。
    1. ビルド

        1. JVM 固有の事情を考えつつ、Dockerfile のベストプラクティスの実現を目指す
        1. JVM のコンテナの場合、コンテナのフットプリントを小さくするために JVM 固有のノウハウが必要

            1. 適切なベースイメージの選択
                - 公式リポジトリからベースイメージを選択する場合、LTS+headless がおすすめ
                - 今だと Debian(headless) 11 LTS

        1. カスタム JRE を作成してサイズを落とそう

            1. デフォルトの JDK の全機能は多くのアプリケーションでは不要
            1. JDK9 でモジュールシステム("Jigsaw")が導入された
                - 使用しているモジュールのみでカスタムランタイムを作成できる。
                - 容量が削減できる！
                - jdeps(依存する JVM モジュールを作成する), jlink(指定した JVM モジュールだけを含むカスタム JRE を作成する)
            1. Dockerfile 内でカスタム JRE を作成できる

        1. もっと発展的な JVM コンテナのビルド手法
            1. Jib とカスタム JRE を組み合わせることが可能
            1. Native Image(マニアック)
                - GraalVM の NativeImage 生成機能を利用
            1. SubstrateVM(黒魔術)
    1. デプロイ

        1. コンテナのリソース制限と暖機運転に注意する

            1. コンテナのリソース制限を考慮して、適切な設定を
            1. JDK が認識してくるコンテナの CPU 制限の設定
                1. `--cpus`
                1. `--cpu-shares`
                1. `--cpu-quota`
            1. JDK が認識してくるコンテナの メモリ 制限の設定
                1. `--memory`
                - JVM のヒープメモリの設定は、コンテナに割り当てられたメモリ量を見て設定される(デフォルト 1/4)
            1. JDK11 で 1cpu, 512mb をコンテナに割り当てて JVM のデフォルトに任せると、シリアル GC が選択されてしまう
                - → Full GC が発生しやすくなる
                - → もう少しメモリを上げるなど検討が必要

            1. 暖機運転をしていない JVM は理想的なパフォーマンスを発揮しない

                1. 暖機運転が済んでいない JVM コンテナを高負荷にさらさないよう工夫する

                1. 対策として暖機運転の自動化
                    1. サイドカーコンテナから暖機のトラフィックを送る
                    1. Readiness Probe が OK となるまで、Service 経由での Pod へのトラフィックが流れないことを利用し、Readiness Probe が開始されるまでの間に暖機運転(1 万回リクエストをなげる)
                1. 対策として ServiceMesh によるトラフィックの制御
                    1. Istio などの Service Mesh を利用すると、Pod に流すトラフィックの割合を 1%単位で調整できる。
    1. 監視

        1. 目的やスキルセットに合わせて複数の手段を使い分ける
        1. k8s でも JVM 標準の監視ツールを利用可能
            - jcmd, jstack など JDK 付属の基本的なツールを使う場合、JDK のコンテナをサイドカーとして追加してそのコンテナからツールを実行する
        1. Java Flight Recorder(JFR) ← OpenJDK にはいっている
            - Java Mission Control(GUI)を使用してプロファイルをグラフィカルに解析できる

        1. CloudNative な監視手法も活用する

---

### RELEASE FAST OR DIE: DevOps を加速させる Universal Artifact "JFrog Artifactory Platform"のご紹介(JFrog)

Time:16:40 - 17:20
Speaker:田中 克典
Slide:
感想: うまく理解できなかったんだが OpenShift みたいなやつか？

Memo:

-   会社概略
    1. イスラエル発の会社

-   DEMO
    1. Maven を使って Artifactory にデプロイ
    1. Docker イメージを Artifactory にデプロイ
    1. Xray 上記でデプロイされたアーティファクトの脆弱性とライセンス違反を検出

-   マクニカグループ
    1. マクニカネットワークス

---

### そのコンテナ、もっと「賢く」置けますよ？

Time:12:00 - 12:40
Speaker: チェシャ猫
Slide: https://speakerdeck.com/ytaka23/cloudnative-days-tokyo-2019
感想: やばい。資料も話し方もすっげーわかりやすい。ファンになってしまったかもしれない。また名前を見つけたら参加しよう。

Memo:

-   クラスタ上の Pod の配置をコントロールする

-   スケジューラは Pod を Node へ紐づける
-   Policy によるスケジューリングの調整
-   k8s はクラスタ内に複数スケジューラを配置できる
-   Pod に対しどのスケジューラ配下にコントロールさせるか指定できる

-   Vertical Pod Autoscaler

    -   実測値に基づいてスペックを設定してくれる

-   スケジューラ完全自作は危険

    -   テストしづらい
    -   Extender までにしとけ。
        -   I/O は決まっているのでテストしやすい

---

### 実録！CloudNative を目指した 230 日

Time:13:20 - 14:00
Speaker:高石 諒
Slide: https://speakerdeck.com/takaishi/cloud-native-days-tokyo-2019
感想: 謎の Pod スパイクのトラブルシュートとか胃が痛すぎる・・・こういった知見はバシバシ皆 output すべき。

Memo:

1. なぜ k8s を導入したか
    - 課題
        1. 物理サーバ投入のリードタイムがボトルネックになっていた
        1. 人の介在がオーバーヘッドになる
    - なぜ k8s か
        1. Challenge
    - とはいえ k8s て運用大変なんでしょ
        1. もし力尽きても全くの無駄にはならない
            - サービスの k8s 対応 = ポータビリティの向上
        1. 得た知見や実施した改善は活用できる

1. k8s の導入で何があったか

    1. 利用状況
        - 46Namespace
        - 稼働中システム例
            1. ArgoCD
            1. HackMD
            1. Drone
            1. 各種 Bot

    1. 導入方法
        1. 学習して慣れていくしかない
        1. 興味を持ったときに、すぐに触れるようにする

1. 導入で発生した問題

    1. 謎のタイミングで特定の Pod に負荷が集中する問題
        1. Prometheus と graphana で解析した
        1. nginx-ingress controller の動きをみてみる

    → 可観測性の強化って重要だなと思った

1. 僕たちは CloudNative になれたのか
    1. クラスター作れるようになった
    1. 本番運用に適用した

-   まずは導入して、動かしていけそうという感触をつかみたかった
-   手作業でできないことを自動化するのは難しい

---

### クラウドネイティブを創る技術

Time:15:40 - 16:20
Speaker:山下 和彦
Slide: https://speakerdeck.com/pyama86/kuraudoneiteibuwochuang-ruji-shu
感想: 2 日間で一番笑えたセッション。でも車輪の再発明ってどうなんだろう？と考えてしまった。

Memo:

-   マネージドクラウドについて
    1. FastContainer
    1. オートスケール
        - prometheus を採用し、ユーザーコンテナなの情報をすべて集約
    1. バックエンドを意識しなくても使用できる

-   DB に格納する秘匿情報は Vault を利用

-   なぜ k8s ではないのか
    1. ペパボはホスティング事業を提供
    1. FastContainer アーキテクチャ
    1. 時代的な要因
    1. 事業差別化
        - 誰でも使えている製品で戦うのか

---

### サーバレス・ネイティブ が お伝えする、フルサーバレス開発の魅力

Time: 16:40 - 17:20
Speaker: 江藤 武司
Slide: https://riotz.works/slides/2019-cloudnative-days/#1
感想: このスライドのボタン・・・押せるぞ！ってなった時、slideshare も speakerdeck もそのうちこっちのスタイルになっていくかも。と思った。スライド内の文字列、コピーしたいときあるもんね。内容はサーバレスアプリケーションはピタゴラスイッチ的な面白さがあると。

Memo:

-   サーバレスは高速に開発できる
    -   アイデアを即、形にできる魅力がある
-   プログラムは直接ラムダに実装、フロントは S3
-   アプリケーション開発に集中できる

    -   周辺システムとも統合されている(オートスケール、監視、ログ, etc )

-   問題
    -   lambda 複雑すぎて問題が発生
        -   タイムアウトが多発
-   対策

    -   実行ランタイムを変更
        -   Java → Node.js(TypeScript)
    -   ※ 2019/7 月現在、Lambda の起動が高速化され、Java ランタイムのコールドスタートでも 1 秒くらいで起動

-   ピタゴラスイッチ

-   JAMStack

  -   最近話題になりつつあり、フロントエンドやウェブの開発などで見聞きするワード
      1. 良いパフォーマンス
      1. 安価で簡単なスケーリング
      1. セキュりティ
      1. 良質な開発者エクスペリエンス

  - 疎結合化による開発ターゲットと責務の明確化

-   https://tokyo.serverlessdays.io/

---

### Istio で実現するクラウドネイティブ時代のセキュリティ

Time: 17:40 - 18:20
Speaker: 三好 俊介
Slide: https://speakerdeck.com/smiyoshi/cloud-native-security-and-istio
感想: k8s と Istio のセットはデフォルトになってきた感があるな。

Memo:

#### 前半

-   Zero Trust Network

    -   何も信じるな、必ず疑ってかかれ

-   導入の手順
    1. まず可視化
        - だれがいつどこにアクセスしたのかわかるように
    1. 制御

#### クラウドネイティブと Istio

-   クラウドネイティブなアプリの運用を楽にしてくれるインフラ技術
-   なにができるか
    1. Traffic Managemement
        - ルーティングなどのトラフィック制御
    1. Observability
        - 通信内容やトラフィック状況などの監視
    1. Security
        - 認証やアクセス制限、暗号化
    1. アプリの変更なしで導入できる
    1. 証明書の管理なしでセキュアに通信
-   クラウドネイティブへの道のり
    1. 可視化
        - 何が可視化できるか
            1. サービスとサービスのつながり
                - どのサービスが通信しているか
    1. 制御
        - デフォルトオフ

-   Istio RBAC の設定例
    1. 名前は default 固定
    1. mode: ON_WITH_EXCLUSION か INCLUSION がおすすめ

## 最後に

-   Wifi(虎ノ門フリーのやつ) はあるが遅かった。自分で持って行った方が良い。
-   軽食が出る
-   水・アイスコーヒー・オレンジジュースはある
-   電源は少しあり
-   名刺は沢山持って行ったほうが良い