見出し画像

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
  ・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日目の記事として書いてみました。


この記事が参加している募集

いつも応援していただいている皆さん支えられています。