2018/12/15 に開催された JJUG CCC 2018 Fall のイベントレポートです。

●イベントのテーマ
JJUG CCCは毎年2回、春と秋に開催する日本最大のJavaコミュニティイベントです。Java関連の技術や事例に関する良質なセッションが行われ、また異なる分野で活躍するJava技術者が一堂に会する場ともなっています。ぜひご参加ください。

■Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話

株式会社ジャストシステム 福嶋航 さん

●システム構成
・概要
　　・企業向けwebサービス
　　・24/7
　　・アクセス頻度は個人向けほど高くない
　　・扱うデータは数百GB〜数TB

・システム構成
　　・ALB > WebServer/UI Container > 内部ALB
　　・素のEC2 > 内部ALB
　　　　・内部ALB > Other Containers

・デプロイ構成
　　・GitLab CI > ECR > ECS
　　・素のEC2はCodeDeploy

・なんでECSにしたの？
　　・AWSに慣れているから
　　・Kubernetesの学習コスト掛かりそう
　　・Fargateのランニングコストが高そう
　　　　今の2.5倍になりそうな試算だった
　　　　ECSであれば、同じアーキテクチャなのでFagateにも移行しやすい

・Dockerコンテナにしなかったもの
　　・Fargateにスムーズに移行できる自信がなかったもの
　　　　・ファイルシステムのボリュームをマウント
　　　　・バッチ/Webサービスが協働

・UI ContainerはSpringBoot
・2段目のALBを通過するうときにWebServerのIPになってしまう
・WebServer > UI Container につなぐようにした

●各自の開発環境 と ビルド・デプロイの流れ
・各自の開発環境
　　Dockerコンテナを複数動かすなら、メモリは16GB以上ほしいよね
　　IDEはEclipseとIntelliJで2分な割合だった

・Issueの単位はまちまち

・コーディング、テスト
　　1コンテナ内に閉じてUT
　　コンテナをまたぐところはMock

・マージリクエストでのレビューポイント
　　担当者以外が保守できるか

・マージ後
　　特定ブランチにpush
　　> mvn clean package
　　> docker-compose build
　　> docker push (ECR)
　　> ecs-deploy
　　> Mattermost

・drainingにかかる時間で、すぐにデプロイされない
　　・ターゲットグループの「登録解除の遅延」
　　　　デフォルト1分
　　・終了処理って1分で終わらないこともあるよね
　　　　ぶつっときられちゃう
　　・延ばすと、ロールバックに時間がかかってしまう

●環境ごとの設定の切り替え
・ベータ環境
　　・Dev
　　・QA
　　　　本番デプロイのリハーサルにも利用
　　・性能評価
　　　　負荷を掛けて、測ってみないとみないとわからない
　　　　コンテナごとに最適なインスタンスを割り当て
　　　　起動パラメータを調整していった

・springのプロファイル切り替えで環境を切り替え

・ブランチ戦略はGitFlow
　　・GitLabCIではブランチと環境を紐づけ

・環境変数の利用
　　SpringBootがファイルより環境変数を優先してくれるから便利
　　ECSタスクの環境変数で、すぐに変更できる

●本番運用でその他に必要なこと
・ログ出力
　　・やりたいこと
　　　　・同一種類のコンテナのログは時系列に見たい
　　　　　　・ZoneA/ZoneC に分けて管理しているから
　　　　　　　どっちにいくのかわからない
　　　　・エラーレベルは監視アラート
　　・仕掛け
　　　　errorだけのファイル出し分けて Zabbix agentが監視
　　　　mainのファイル > fluentd > Kinesis Data Firebase > S3
　　　　※tee > grep --line-buffered ログレベルがエラーのもの >> error.log
　　・監視内容
　　　　Docker space のお掃除をcronで毎分動かしている
　　　　ALBからヘルスチェックを受け取るエンドポイントを用意
　　　　　　※ここでデータストアなど、自分が必要な接続の確認も
　　　　　　500を返すと即死だから、考慮が必要

・未解決事件
　　・ALB > Container > ALB がたまに 502
　　　　今はリトライで対応

●まとめ
・誤操作でサービスを落としてしまったが、ECSが1分で復旧してくれた！
・監視はプログラムの外側と、内側

■マネーフォワードのアカウントアグリゲーションの現状と課題点について／Selenium WebDriverとヘッドレスChromeを用いたスクレイピング

株式会社マネーフォワード 中本武志 さん
株式会社マネーフォワード 内波生一 さん

■マネーフォワードのアカウントアグリゲーションの現状と課題点について
●Mission/Vision/Value
・Mission
　　お金を前へ。人生をもっと前へ。
・Vision
　　すべての人の「お金のプラットフォーム」になる。
・Value
　　UserFocus, Technology Driven, Fairness

●事業領域
・Money Forward Home
・Money Forward Business
・Money Forward X
・Money Forward Finance

●個人向け：自動家計簿・資産管理サービス
・口座連携
・自動分類
・レシート撮影

●法人向け：クラウド会計の特徴
・取引明細の自動取得
・自動分類

●アカウントアグリゲーションとは？
・いろんなサービスに散らばっている情報を1箇所にあつめる
・毎分 5,000口座から収集 > 50億レコード
・仕掛け
　　ユーザと同じ様にwebサイトを見て、必要な情報を抜く(スクリーンスクレイピング)
　　HtmlUnit + カスタマイズ > ヘッドレスブラウザ

●HtmlUnit
・ブラウジングの根っこからカスタマイズできる
　　> 独自ブラウザな扱い
・金融機関のサイト以外も連携するようになった
　　> 動的なサイトへの対応も必要になった

■Selenium WebDriverとヘッドレスChromeを用いたスクレイピング
●対応状況
・対応金融機関 2,600
・API連携のアグリゲーションも増えてきている、が大多数はスクレイピング

●スクレイピングの課題
・Html Unitが対応していない仕様
　　> 同等の処理を用意した
・Html Unit本体が対応していないパターン
　　> 報告して、今は対応が載っている

●課題
・連携先のリニューアルでスクレイピングできなくなる機会が増えた
　　> ヘッドレスChromeへ

●ヘッドレスChromeの使い方
・制御方法
　　・puppeteer(NodeJS)
　　・Chrome DevTools Protocol(CDP)
　　・WebDriver
・CDP
　　・WebSocket / JSON形式
　　・要素にアクセスしたり操作しようとすると煩雑
・Selenium WebDriver
　　・ブラウザ共通のAPI
　　・JSON Wire Protocol > 各種Driver
・chromedriver
　　・chromium向けのWebDriver実装
　　・CDPコマンドを渡すAPIもある
　　・chromedriverのテストコードが使い方を把握しやすい
　　・findElement は結局JSで実装されていたり
・スクレイピングに必要な要件
　　・プロキシ
　　・Cookie
　　・ファイルダウンロード
　　　HtmlUnit:
　　　　同一プロセス>アプリから直接アクセス。完了イベントも取れる。
　　　ヘッドレスChrome:
　　　　別プロセス>ファイルシステム経由。完了イベントどうしよう。
　　　WebDriver:
　　　　Performance Logを有効にしてイベントを取得できる

●アグリゲーションシステムへの組み込み
・WebDriverを使う金融機関だけ、専用サーバに振り分ける
・chromedriver は daemon 起動
　　・重そうだったので
　　・並走数は計測して調整
・追加機能
　　・chromeを確実に閉じる
　　・テストではないので、タイムアウト>Exceptionをラップ
　　　　指定時間を過ぎても例外を投げない（握りつぶす）
　　　　エラー画面が表示されたら即エラー

●使ってみた感想
・結構メモリを食う
　　1つ120MBくらい
・chromeのバージョンアップどうしよう
　　aptだと最新しか取れない
　　リポジトリをコピーする？

■思考停止しないアーキテクチャ設計

川島義隆 さん

●「流しのアーキテクト」になりました
・起業クエスト
　　https://kigyo-quest.netlify.com/

●Software Architecture
・IEEE1471
・設計において重要なもの
・あいまいなもの

●非機能要求からアーキテクチャ設計
・非機能要求
・アーキテクチャパターン
　　> アーキテクチャ設計

●品質特性シナリオ
・シナリオ
　　刺激発生源
　　刺激
　　成果物
　　環境
　　レスポンス計測

・可用性のケース
　　ヘルスチェック
　　サーバ樹応答
　　プロセス
　　平常状態
　　ダウンライムなし

・可用性の戦術
　　異常の検知
　　異常状態からのリカバリ
　　　　準備と修復
　　　　再起動
　　異常状態の防止

・品質特性間のトレ−ドオフ
　　全部は取れない。
　　Microsoftのページにこの表が出ているよ。

●アーキテクチャパターン
・責務の割り当て
・データモデル
・リソースのコントロール
：

●代表的なアーキテクチャパターン
・レイヤード
・イベント駆動
・マイクロカーネル
　　薄いEclipse本体にpluginが沢山
・マイクロサービス
・スペースベース

●アーキテクチャパターン間のトレードオフ
・アジリティ
・デプロイ容易性
・テスト容易性
・性能
・スケーラビリティ
など、どれを取りに行くかでも決まる

●アーキテクチャ設計にどれくらい時間を掛けるか
・開発時間　＋ アーキテクチャとリスク削減時間　+ やり直しの時間
・アーキテクチャ設計に書ける時間とやり直しの時間はトレードオフ
・規模にもよる

●十分かをどう評価する？
・品質特性シナリオを使う

●課題をいろんな視点からみる
・リスク
・分かってないもの
・顕在化している問題
・チームでの理解のギャップ
・崩れ具合
・ビジネス環境の変化

●どうメンテナンスしていくか
・ADR Architecture Decision Records
　　・メンテされない
　　・意思決定性がどうだったかを残す
　　　　・選択肢がどれだけあって
　　　　・メリデメが何で
　　　　・なぜ選んだのか
・markdownで書いて、ソースと一緒に管理

●それでもアーキテクチャ上の考慮漏れが出る
・教科書通りで満足しない
・思考停止の分類 by 川島さん
　　・限界意識
　　　　ぜったい。めんどくさい。
　　・無意識
　　・特別意識
　　　　私のやっていることは特別
　　・ひきこもり
　　・卑屈
　　・責任転嫁
　　・子供扱い
・機能要求、非機能要求 > アーキテクチャ要求

●例：カテゴリごとの件数表示（職種ごとの年収）
・そのままだと一番件数が多いテーブルをフルスキャンしてしまう
　　> 検索エンジンのAggregate
　　> リザルトキャッシュ
　　> デグラデーション
　　　　キャッシュが停止している場合、利用箇所だけ出さなくする
　　　　全体を落とさない

●アーキテクチャ設計した気分になるのを防ぐ
・NFRからのアプローチ
・ASRからのアプローチ
>アーキテクチャ大全 執筆中！

●例：柔軟すぎる設計（ETCの割引）
・ルールを全部テーブルで持ってる
　　> メンテミスで落ちる
　　> 予期しないデータパターンでおちる
・適度な柔軟さに落とす
　　> 保証するデータパターンを網羅するテストが書けるか？

●当初の思想/環境とのズレ
・緊急リリースに間に合わない
・相手先システムにリソースがないから、こちらで対応
・開発スピード重視 > 可用性重視

●技術的負債バジェット
・顕在化の確率 x かかる費用
・対処した時の顕在化確率 x かかる費用
　　> 技術的負債 時価総額

●アーキテクチャ設計は終わりのない仕事

●参考文献
・Software Architecture in Practice
・Design it!
・Software Architecture Patterns

■エムスリーでのKotlinへの取り組み

エムスリー株式会社 滝安純平 さん

●M3とは
・m3.com、m3.comアプリ
　　医療事業者専門サイト
・医師が無料で情報収集できる
・製薬会社が低コストで医師に営業できる

●Kotlinとエムスリー
・歴史
　　・2016 AndroidアプリをKotlinで
　　・2017 サーバーサイドKotlin
　　・2018 新規アプリも続々とKotlin

・使っているチームは、半分くらい

・Kotlinを選んだ理由
　　Java > BetterJava
　　アプリエンジニアがサーバサイドもつくるから

・技術選定の方針
　　メンバーの習熟度
　　利用できるライブラリ
　　既存システムとの連携

●JavaからKotlinへの移行
・徐々に変えていく
　　8割完成済みのjavaプロジェクトにkotolinを途中導入した話
　　・新規追加のクラス、テストはKotlin
　　・機能追加が完了したら全てKotlinにする

・なかったコトにする

・全部まとめて書き換える
　　IntelliJで自動コンバート
　　Kotlinらしくはならないが、できる
　　開発が活発なタイミングで

・他の機能開発と調整
　　・テストを用意しておく
　　・コンバート中は開発をストップ
　　・テストはJavaのまま

・リグレッションテストを充実させる
　　・Golden file testingを採用
　　　　APIのレスポンスをファイルにしておく
　　　　実行結果と比較してリグレッションテスト
　　　　このjsonファイルを自動生成させる

・Swagger Codegen, UI (OpenAPI)
　　Kotlin + SpringBootでAPI作成 > client生成 として利用

・GraphQLも似たようなメリットが得られそう

●Androidの取り組み
・2016 OKRとしてMRくんアプリのリニューアルを開始

・OKR
　　目的 -> 目標
　　大きな目標を立てよう
　　目標は定量的に
　　クリアしきらなくても良いよ

・OKRで定めているから、書き換えの手間に手が出せる

●JavaとKotlinの違い
・Optional or Nullable
　　Guavaで頑張ってきた > Kotlinだと短く書ける
　　インスタンス生成しないので軽量

・Lombok or data class
　　Lombokは黒魔術
　　・Builder > 名前付き引数
　　・Kotlinコンパイル のあとで Lombokのコードが刺されるので、Kotlinからは見れない
　　　　モジュールを分けたり、Delombok

●アプリサイズの増加
・そのままだと500MB増えた
　　> ProGuardなどで削減できる

●メンバーへの浸透
・自動変換できるからJavaエンジニアの導入は楽
・KotlinらしさはLintとコードレビューで
・wiki/slackで議論

●コーディング規約
・スタイルガイド
　　・JetBrains
　　・Google
・Lint
　　・ktlint
　　・detekt
・IntelliJでもサポートされるようになった

●テストが読みやすくなるよ

■Java を活用したマイクロサービスのための Kubernetes 活用

日本マイクロソフト株式会社 寺田佳央 さん

●関連情報
・事前準備のネタはデブサミ関西で話しました
・KubernetesのネタはGitHubに置いてます

●伝えたいこと
　　新しい技術に触れるとトラブルはつきもの
　　我々エンジニアは、つまづきながらでも乗り越えて
　　良いサービス、製品をつくっていこう！

●Javaのコンテナに関わるupdate
・JDK9 カスタムJREで小さいイメージを作れる様になった
・JDK10 Containerの下のOSの情報が取れていたが解消雨された
・JDK11 XMLを扱うパッケージが削除された
　　多分はまります。。。
　　3年では対応が遅かった。半年更新で世の中の流れに乗れるようになった。
　　> 乗っていきましょう！

●Docker
・latest tag は使わないで！
　　> BuildIdを使おう！

・小さなサイズのイメージを作ろう！
　　> SpringBoot, Microprofile以外もあるよ！
　　　　Light4J など、独自仕様で軽量化している。

・DockerHubのイメージは安全？
　　> Aqua Security, Twistlock などでセキュリティチェックしよう！

●Kubernetes
・なんでもかんでもk8sではない
　　・Managed, OpenShift, CloudFoundry...
　　　　必要なときだけ使えば良い
　　・Containerを動かすServerless
　　・FaaS

・k8sの進化は早い！
　　> 覚悟が必要

・本番環境ではいろいろ考える必要がある

・すべてのk8sの機能を利用する必要はない
　　J2EEと同じ道をたどっているように見える
　　他の便利なものもある

・複雑な構成を作らない
　　運用構成を極力

・大規模k8sクラスタを構築しない！
　　アプリがマイクロサービスなのに、k8sがモノリシック
　　　　k8sのバージョンアップ
　　　　下のVMにパッチ
　　クラスタレベルで複製できるサイズに留めよう！

・Deploymentの設定YAML
　　HelloWorldは本番では動かせない
　　リソース使用量の制限
　　Label & Selector

・PersistenceVolumeの使い所
　　僕は別の方法をおすすめしますw
　　SDKを使用したファイル保存、更新機能実装のススメ
　　VNet経由でManaged DBを利用のススメ

・k8sのversion upには注意
　　Managedで用意されているボタン、コマンド一発は、やめましょう
　　失敗した時どうなる？どうする？
　　古いバージョンの設定が新しいバージョンで動くとは限らない
　　　　> 新規にバージョンアップしたk8sクラスタを用意
　　　　> 開発、テスト、本番環境も同様だよね

・問題が発生した時に何をする？
　　クラウドベンダーが障害を誤っている間に、回復させなくては！
　　自力で解決はできないとね

・Kubernetesを本番環境に適用するためのTips

・VS Code x AKS で Java on K8s をリモートデバッグできる
　　※まだまだpreview版

・VirtualKubelet 2018-12リリース！

・AzuleDevOps無料ではじめられますw

●トラブルを乗り越えて、より良いサービスをつくっていきましょう！

■オイラ大地の18年拡張し続けているECサイトをSpring Bootとk8s on Azureでマイクロサービス化する事例

オイシックス・ラ・大地株式会社 小林弘明 さん

●Oisix ra daichi
・これからの食卓、これからの食事
・会社は3ブランド
　　・略称は、オイラ大地
・Oisix
　　・定期宅配：おいしっくすくらぶ

●OisixのECサイト紹介
・2000年の創業当時からJava
　　> J2SE 1.3
・流れに沿って都度リフォーム
　　・1.3 > 5 > 8
　　・Shift-JIS > UTF-8
　　・なし > CVS > SVN > Git
　　・なし > Ant > Maven > Gradle
・開発フローや組織体制は半年で見直し
　　・Growth Hack
　　・DevOps
　　・SRE
　　・Infra as code
　　・Twelve-Factor App

●ECサイトの問題点
・品質の維持
　　提供したいサービスレベルは上がり続ける
・ローンチスピード
　　より多くのサービスを提供
　　> より早くPDCAを回したい
　　> よりローンチを早く
・スケーラビリティ
　　利用者数増加 > ボトルネックの特定に時間がかかる > 対応も大変
> マイクロサービスへ

●マイクロサービス化の方針
・ストラングラーパターン
　　・24/365
　　・一気には無理
　　　　> 徐々に切り替えていこう

・Azure利用のマルチクラウド
　　・Lift&Shiftを検討した
　　・システム的には可能
　　・まわりの仕掛けがデータセンターで動いていること
　　　を前提にしていた
　　　　> 断念。DCはそのままのこし、徐々にAzuleへ。

・共有データベースの段階的な分離
　　・DBの分割を検討
　　・アプリとDBが密結合
　　　　複雑なjoin
　　　　トランザクション
　　・アプリだけ分割、DBはそのまま

●なぜAzure？
・アプリはSpringBootを選んだ
・インフラはKubernetesを選んだ
　　> Managedにしたいね

・Azureでk8s動くよ。 
　　> え、Azure？
　　> 寺田さんがいる
　　　　> 教えてもらいに、Macを持って品川へ
　　　　> ハックフェスト
　　　　　　> AKSが正式アナウンス
　　　　　　> 専用回線を引いて利用開始

●マイクロサービス事例
・ログ検索サービス
　　ECサイトの大量のログからピンポイントで取得
　　・構成
　　　　DC.アプリ
　　　　　　> AWS.Elasticsearch
　　　　DC.社内システム
　　　　　　> Azure.AKS.ログ検索サービス
　　　　　　　　> AWS.Elasticsearch

・受注確定バッチ
　　週1の定期宅配 > 特定の曜日に大規模バッチ
　　リソースの切り替えに再起動が必要
　　・構成
　　　　DC.Oracle
　　　　　　> Azure.AKS.起動バッチ
　　　　　　　　> StorageQueue
　　　　　　> AKS.確定バッチ
　　　　　　　　> AzureMySQL > DC.Oracle
　　　　　　　　> LogAnalytics
　　・マルチクラウドなので通信時間が遅延
　　　　> 確定バッチの並走数を増やして対応できる
　　　　　　> でもコネクション貼りすぎ問題で、トレードオフ

・商品サービス
　　商品系マス歌はアクセス頻度が最も高い
　　キャッシュをAKSに移動
　　・構成
　　　　DC.アプリ
　　　　　　> Azure.AKS.商品サービス
　　　　　　　　> Azure Redis Cache
　　　　　　　　> DC.Oracle
　　・キャッシュがないとひどいことに
　　　　cronで先にキャッシュしている
　　　　> Azure MySQLにしたい

■「マイクロソフト牛尾さん渡米直前記念」 　外資系企業で働くエンジニアの生産性向上物語

Microsoft Corporation 牛尾剛 さん
日本マイクロソフト株式会社 寺田佳央 さん

●自己紹介
・牛尾さん
　　電気工学科 > NEC > 豆蔵 > 独立 > Microsoft
・寺田さん
　　SIer > Sun > Oracle > Microsoft

●US本社への移動、背景/動機/心配事などは？
・コンサル、アジャイルコーチとかふわっとしたのは得意
・テクニカルスキルは低い認識
　　> Microsoftで修行したくて入った
　　　　> アメリカのレベルが高い！修行したい！
・上司にアメリカ行きたいって話していたら
　何年もかけてアレンジしてくれていた
　意外なタイミングで、話が来た

●ブログなど数多く書いてますが、忙しい中どう時間をつくっている？どんな動機？
・昔と今は動機が違う
　　・エバンジェリストの頃は、目立たないといけなかった
　　・バズらせるテクを教えてもらっていた
　　　　はてぶのアルゴリズムとか

・バズらない系のブログも書いている
　　・Qiitaは自分の勉強用
　　・プログラミングの師匠（かずきさん）
　　　　ブログでコードもうまくなった。
　　　　ヒトに説明する体で、小さい整理内容をポスト。
　　　　この繰り返し。

・ちょっと試したことでもブログに書いておくと蓄積されていく
　　ここから話が広がるかもしれない

・海外が相手だと、ビジビリティがない
　　ちょっとでも価値があるかもしれないことは英語でポスト

●US出張時、彼らが実践していたことから学ぶことはありましたか？
・基本的に楽をしようとしている
　　会議とかでも、無駄ならすぐ終わろうとする

・上の役職まで、 k8sのPodが〜 とかで通じる
　　リュックを背負った兄ちゃんが、突然現れて、ハックフェストが決まることも

●今一番イヤな仕事は？
・経費精算w

●「転職」を、どう考える？
・Microsoftに来て、環境が良いからダメ人間になっていっているw
　　無駄な作業が少ないし、技術に集中できる
　　社長時代を含めて、今が一番給料高いw
　　外資系を体験した方が良い
　　　　バンバンやめて、みんな外資系に行けば良い

●家族を持っていると、動きづらいのでは？
・考え過ぎでは？
　　自分がハッピーになるために、やりたいからやる。
　　家族だって、所有物じゃない。
　　みんながハッピーになるには？を考え続ける。
　　口に出すことで動きはじめる

●牛尾さん、英語うまくないけどめっちゃコミュニケーション取れるのはなぜ？
・40を越えてから勉強した
　　最近は学び方が確立されている
　　練習すればできる
　　　　英語の26音
　　　　シャドーイング（歌の練習と同じ）
　　　　講演マニュアル
　　難しいで止まったら終わり

●寺田さんがベラっベラに英語が喋れるのはなぜ？
・コミュニケーションを取りたいから
・Sunの頃は、そんなになかったけど
　Oracleになって、JavaOneのセッション構成を考えたときに
　意見と戦わせる必要も出てきた
・双方向で気づかいができないとね
↓
・エンジニアの場合、2nd langで話せる程度の人ばっかり
・みんな下手

●「英語の読み書きの速さ」がエンジニアの差
・最新情報の処理スピードが直接響いている
・descriptionで中のしくみまで想像できる

●2nd langで他の国の人達が習熟が早いのはなぜ？
・日本語が一番、英語と遠いらしい
・「エンジニアは最新情報を収集できなかったから終わるから」という危機感
・翻訳するのではなく、英語は英語のまま理解する
　　readingなら多読。段階別のがあるよ。
　　英語版のドラボンゴール
　　シャドーイングで口を慣らす

■感想

Container、Kubernetes、マイクロサービス、Webスクレイピング、Golden file testing、アーキテクチャ設計、サーバーサイドKotlin、エンジニアの働き方 と、幅広いお話を伺えました。

最近、javaにふれる機会が減ってきていましたが、改めて幅の広さと懐の深さを感じた一日でした！夜に仕事が入っていたので参加できませんでしたが、次回は懇親会も参加したいです。

スピーカーの皆さん、運営の皆さん、ありがとうございました。

DevLOVE Advent Calendar 2018 15日目の記事として書いてみました。