2018-12-15 JJUG CCC 2018 Fall
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
・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日目の記事として書いてみました。
いいなと思ったら応援しよう！
