はじめに

関ジャバ主催でマイクロソフト寺田さんのワンマン・セッションが開催されたので行ってきました。既に同テーマのセッションがJava One　Tokyoなどで行われて話題になっていますが、評判どおりのとても参考になる内容でした。

概要

関西Javaエンジニアの会 [大阪] 7/12 - クラウド・ネィティブ
日時：2017/07/12(水) 19:00 〜 21:00
場所：日本マイクロソフト 関西支店

テーマ

クラウド・ネイティブなスケーラブル・アプリ開発のために
12 Factor App on Kubernetes on Azure

参考（元ネタ）

• Java One Tokyo 2017の資料：Java EE 開発者のための、今から取り組む Microservices 開発
• de:code 2017の資料： クラウド ネィティブなスケーラブル アプリ開発のために〜12 Factor App on Kubernetes on Azure

⇒今回は時間があるためこれらを元にしつつ関ジャバオリジナルVer.で進めて頂きました

事前アンケートの結果

Javaサーバの利用状況
1位：Tomcat

組み込みコンテナ（実行可能 jar）に移行済みの場合、どのフレームワークへ移行したか
1位：Spring Boot

詳細は後日ブログに書く予定

本編

（※開発プロジェクトで既にマイクロサービス化が進んでいる人…5名ぐらい）

マイクロサービスについて

⇒どこから手を付けていいかわからない
⇒最新動向の話をテーマにしても実際は導入が難しい
今日のテーマ⇒マイクロサービスに近づく方法

オンプレで動いていたものをそのままクラウドに移行
⇒クラウドのメリットを得られない

マイクロサービスの必要性

（※必要と答えた人…半数ぐらい？）

知識・ノウハウは技術者として必要
⇒なんでもかんでもマイクロサービスではない
⇒モノリシックorマイクロサービスの二者択一でもない

• マイクロサービスを何も考えずに進めていくと破綻する
  • マイクロサービスがハッピーにするのではなく、マイクロサービスでハッピーになる
  • 自分たちのサービスに特化したやり方を考えて実現していかないと効果は得られない
  • 考えないと失敗する。今まで以上に考える必要がある。

◎一番駄目なパターン

• とりあえずMSA
• Docker化したい

◎MSAでなくてもできる

• いち早くサービスを提供
• 柔軟にスケール
• 独立したサービスづくり

◎MSAが有効なパターン

• 耐障害性
• 変更に強いシステム（※これが一番のメリット）

マイクロサービスを導入しているか？（海外）

• 導入済み…15%
• 既存サービスをマイグレーション…25.4%
• 新規サービスで導入…35.8%
• 予定なし…23.9%

アメリカでは特に、今までのビジネスがいつ潰されるかわからないという危機感がある
日本でも楽天などは同じ傾向

• いいチームづくりが大切
  • ドキュメントは無駄
  • チーム力が重要
  • モブプロ…いいチームでないとできない

The twelve-factor app

（※Kubernetesさわったことある人⇒2,3人）

DEIS…ワークフローエンジン
http://deis.io/
http://qiita.com/wataru420/items/4bc7c52313d5d06a847c

ハンズオン
https://github.com/yoshioterada/DEIS-k8s-ACS

ソースコード管理

【従来】1つのリポジトリで複数サービスを管理
【MSA】サービスごとにリポジトリは分ける
⇒サービスの変更履歴が把握しやすい

どうやて実装（プロセス）

• ビューとロジックを分ける
• フロントエンドはなんでも良い
• バックエンドはRESTful Web Service、JSONを扱う
• ステートレスで作る
• UIとバックエンドサービスを分割する

セッション管理

【従来】アプリケーションサーバの機能を使って実現
【MSA】アプリケーション・サーバ依存をやめる
⇒セッション情報を外出しする

Inmemory Grid

• GEODE
• hazelcast
• Infinispan
• など

アプリケーションサーバのセッション管理はセッション情報が大きくなるとスケールできない

並列処理・非同期・ノンブロッキング

非同期←これからMSAを学ぶ人は勉強必須

同期か？非同期か？
⇒二者択一ではなく同期か非同期かをちゃんと考える

ブロッキング・ノンブロッキングも重要
⇒ブロッキングすると並列処理で特定のサービスが待ちによりたまる

サーキット・ブレーカー

特定サービスの遅延や障害時にサービスを切り離して回復させる

• HYSTRIX
• Apache Commons
• failsafe

共有ライブラリ（依存関係）

（※共有ライブラリを扱っている人…6,7割？）

• 共有ライブラリは切り離す
• サービス全体で共有するのではなくそれぞれのサービスごとに共有する

ビルド⇒プライベートリポジトリを立てる

• Sonatype…3,4割？
• JFrog Artifactory…3,4割？
• myget
• PACKAGE DRONE
• など

リソース設定を柔軟に（設定、バックエンド・サービス）

• どこの環境でも動くようにする
  • 外部環境の設定⇒プロパティでDB接続設定など

環境変数or設定サーバ
⇒環境変数から設定を読み込むようにする

ビルド・リリース・実行

DEISを使ったビルド・リリース
迅速なロールバックが可能

廃棄容易性

1. Azure Container Service VMのスケール
2. k8nのpodレベルでのスケール
3. DEISにデプロイしたアプリケーションのスケール

自己完結で軽量に動くアプリになる
ポートバインディングを通してサービスを公開

開発・本番一致

• 開発と本番環境は統一する
• ホットデプロイから継続的デプロイ
• 夜中とか週末とかやめよう
  • 本番環境上でテストして切り替えてリリースする

実現方法

• Feature Flag
• Bule/Green Deploy
• A/B Test
• Canary Test
• Red/Black

JavaのFeature Flag…toggz

運用・監視ログ

生のログを見るのはつらい
全ザービスのログを外に吐き出すようにする
elasticsearchなどで確認

データベース連携

1. 1サービス1データベース（RDMBS on 1VM）
2. 1サービス1データベース（RDMBS on マルチVM）
3. データベース連携（メッセージ連携）
   • メッセージングシステムを利用
4. CQRS（Read-Write分離）
   • 例えばReadだけスケール

完全なトランザクション管理が必要なところはメッセージ連携でなくても良い
⇒適切な方法を考える

さいごに

障害は起きる
↓
【従来】起きないように頑張る
【MSA】起きても大丈夫なように作る

※分散コンピューティングを意識したシステム開発

どこで障害が発生するか？⇒全部で起きる

今だから再びオススメの一冊

Release It! 本番用ソフトウェア製品の設計とデプロイのために

所感

マイクロサービスが良いとか悪いとかではなく、自分たちにあったやりかたをよく考えて実現していくしかないんだという現実を直視したうえで、より良いサービスの形を模索するための考え方のヒントを提示してもらえた内容だったと思います。新しい技術はたくさん出てきて勉強することがたくさんあって大変だと冒頭でおっしゃっていましたが、本当にそうだと思います。べんきょう！べんきょう！