せてぃーずノート

Javaのイベント参加レポートとかを書いたりします。

Mackerel / NewRelic / Elasticsearch Seminarに行ってきた

奇跡の二日連続更新なので初投稿です。 モニタリングをテーマに、3つのツールの違いがよくわかるセミナーでした。

ご挨拶

モニタリングをしていないとサービスが動作しているかもわからない.
十分な考慮の元で設計されたモニタリングインフラストラクチャが重要.
十分な考慮=ビジネスの特性等を把握.

Linux OSから見るMackerelのパフォーマンスモニタリング

何を見ればいいかわからない
グラフを見てもどこが悪いかわからない
そんな人向けのLinuxのモニタリング

  • Mackerelの特徴

    • もともとははてブはてなブログを監視するツール。10年前から使っている
    • 3年前からSaaSとして公開。はてな自身がエンドユーザーでもあるのでUIには凝ってる
  • 利用には、サーバーにMackerelエージェントをインストールだけ。エージェントからMackerelのSaaSHTTPSで送信。

    • Mackerelからエージェントを導入したサーバーにアクセスすることはないからセキュア

Linuxモニタリング

ロードアベレージ

  • 実行待ちのプロセス数とディスクIO待ちのプロセス数の合計
    • 高い場合はCPUやディスクIOが詰まってる状態
    • uptimeやtop等で確認できる
  • uptimeの数値は1分間、5分間、10分間の平均
  • Mackerelは標準で5分平均をサポート

CPUの使用率

100%の場合、どこが使っているかを知るのが重要

  • topコマンドのCPU使用率は全コアの合計。1を押すとコア別に見れる

モリーディスクioFSは省略.
Mackerel本を読んでね.

モニタリングしたものをどう活躍するか

根本原因をどうやって見つけるか

  • ロードアベレージのアラートは処理がさばききれてない可能性。ただ、即障害とは限らない
    • スパイクなら問題ない
    • 負荷がかかっているコアが1個なのか全部なのか
    • 継続的に見ないとダメ
  • 「実際にさばいている処理<捌くべき処理数」の状態が継続していないか?
    • 高まり続けているのは処理待ちがたまり続けてる
    • 高い場合でもコア数を確認するのが重要
  • CPUかディスクがボトルネック
    • CPUのメトリックから原因を読み取る
  • ディスクIOの場合はSSDに換装する 

  • userが高い場合はアプリケーションのループや処理が原因

    • 金の弾丸(コアを追加、コアのスペック向上)で解決できる場合も
    • 1個のCPUで止まっているなら、コアのスペック向上
  • CPUが常に低い場合はサーバーがオーバースペック。コストダウンのチャンス。

まとめ

  • パフォーマンスモニタリングは難しい
  • 見るべき値や条件はサービスやサーバーの役割でちがう(Webサーバー、DBサーバー)
  • 勉強しておけばアプリエンジニアとしての付加価値に
    • スパイクなのか少しずつ上昇しているかを知るためには時系列データが必要
    • 過去のデータは取れないからモニタリングツールは重要
    • 問題が起こる前兆もわかる

QA

  • Q:コマンドで監視できるけどMackerelを導入する理由は?

    • A:コマンドを打たなくてもよくなる。毎分実行、加工、失敗した時云々・・・。DB、グラフ、分析を自分でやらなくていい。
  • Q:HinemosとかZabbixとのちがい?

    • A:セルフマネージドは監視対象が増えた場合のチューニング等のメンテナンスを自分でしないと行けない。 また、Zabbixを監視するZabbixとかも必要になる。 MackerelはSaaSなので何もしなくていいし、他のツールやサービスと連携できる

New Relic によるアプリケーションパフォーマンス監視入門

New RelicはSaaS型のパフォーマンス分析ツール。
パフォーマンス、アラート、障害分析機能(切り分け)等様々

APM

  • APM=ApplicationPerfomanceMonitoring

    • エージェントをインストール
    • Java、Go等の7言語に対応
  • 遅いトランザクションや直近のアラートが観れる

    • アラートは集中管理。通知チャネルや設定条件が豊富
  • ダイナミックベースラインアラート

    • 普段の振る舞いと違った動作をしたらアラート。機械学習で過去の傾向を分析
  • トランザクションタイムからどのトランザクションが遅いかわかるので深掘りすることが可能

    • アプリのどの部分で時間がかかっているか
    • SQLの場合、発行されたSQLと時間
    • 外部サービスにかかった時間も観れる
  • 内部サービスの呼び出し階層が観れる

    • 一覧で赤いとアラートが発生している
  • インストール後にアラート設定とユーザー満足度(平均レスポンスタイム)の閾値を設定することを推奨

  • デプロイトラッキングで、トラブルが多いデプロイしたタイミングを監視できる

    • デプロイ前後のパフォーマンスが比較
    • デプロイした時刻が残るので調査に役立つ

応用編

ソースコードを修正することで、さらなる情報取得が可能

  • カスタム属性

    • 例えばECサイトのマルチテナントでショップIDをカスタム属性として追加
    • ショップごとにパフォーマンス追跡が可能
    • 入れない場合、アプリ全体でしか見れない
  • カスタム計測

まとめ

  • NewRelicはAdobe、Sansan、楽天

    • パフォーマンスに売り上げに繋がるサービスで多く採用
  • ブラウザの監視も可能。アプリケーションの監視と組み合わせ、1つのダッシュボードで観れる

  • 最新動向としては、AIに注力

    • 過去のデータから今後パフォーマンスで問題になりそうな情報と対策を提供
  • NewRelicを導入して開発とインフラのコミュニケーションが改善

    • インフラチームが最初に障害に気がついたとき、エビデンスを持ってコミュニケーションできる
    • 開発もパフォーマンスに対する意識が高くなった

Elastic Stackによるログの監視入門

ElasticStackは100%OSSで有償サポート
ELKにBeatsというOSSが追加された.
バージョンを5.0で全部統一

昔はバージョンが揃ってなかったので、間違った組み合わせで使って「動かない」というissueが乱立

Beat

  • Go言語エージェント。
    • データがあるところに仕込むと取り出してくれる
    • 送り先はSearchかLogstsh
    • File、メトリクス、ネットワーク、Windowsイベントログ、パケット、そのほかにも色々

Logstash

  • Rubyで書かれている
    • JRubyで実装されているため、Javaが必要だった
    • フィルタリングのようなパイプライン処理が可能

ElasticSearch

Kibana

  • nodejs
    • ElasticStackの窓口

導入とか

  • 大規模な場合はBeats→kafka→Logstashの構成でElasticsearchの負荷を下げる

  • nginxやApache2のログは、ファイルの場所とElasticsearchを指定するだけ

  • PacketBeatsはプロトコルを監視

  • パケットを指定するだけなので再起動は不要で後から差し込める。

    • オーバーヘッドがそこそこある。本番ではパケットをミラーリングして監視するといい
  • FilebeatやLogstashは1行1データではなく複数の行も観れる

    • パターンマッチを利用する(先頭がスペースだと複数行のデータとして扱う)
  • X-PackはClosedソース

    • 検索のクエリでアラートが可能(Kibanaにはアラートがない)
    • 例:10秒以内にエラーが5件
  • 機械学習でパフォーマンスを予測した曲線

    • NewRelicと被ってる
  • Elasticsearchは検索エンジンなので、パターンでログを検索して、それ以外のログが出たらアラートといった使い方のできる

感想

あまり情報を追いかけていない分野だったけど、サービスのクオリティが非常に高いと思った。

どのツールも得意な分野があるので組み合わせて使うのがいい感じ
先日のioドメイン障害といったリスクもあるけど、SaaSにお任せは楽だし機械学習で障害傾向の分析まで自分で構築するのは困難。機会があれば積極的に利用していきたい.

JSUG勉強会 2017年その7 俺たちのマイクロサービスへ行ってきた

週末風邪で倒れてたので初投稿です。
教科書の話ではなく、実プロジェクトの経験ベースの貴重な発表がきけました。

無理をしないマイクロサービス

資料は非公開。
実際にマイクロサービスを導入したときの話。

無理をしない

自分たちの体制や得意な技術に合うやり方で、これまでやりたくてもできなかったことをする。

実際にやったこと

  • 最初はBigMonolith。リリーススピードをあげたい

    • コンフリクトが発生すると解消に時間かかる
  • バックエンドをチーム毎に分割して、フロントエンドにUIサービスを置いてAPIで呼ぶ

    • フロントエンドのUIが全チームで共有するため、フロントエンドでコンフリクトが発生
  • コンポーネント指向のSPAやBFFは、サーバーサイドスキル中心のチームで採用するのは厳しい(無理をする)

  • 各サービスがUIまで持つ完結したアプリケーションの構成

    • 注文、カート、オーダーといったアプリケーションが画面遷移で繋がってる構成
  • ユーザー情報の連携はもともとあったSSOの仕組みを利用

    • cookieにJWTで暗号化したユーザー情報を保存してサブドメインで共有
    • PreAuthenticatedAuthenticationを利用して連携
  • リンクのURLはSpringCloudConfigで一括管理

    • 開発中とプロダクションで値の切替もできる
  • 他のサービスと連携する部分はAPI

  • API呼び出しで障害が発生すると、障害の連鎖で最悪LBがダウンする

    • 障害の連鎖を防ぐためのサーキットブレーカー(Hystrix)の導入
    • Fallbackが注目されがちだが、障害の発生したAPIにアクセスさせないことが重要な目的
  • APIにHystrixのアノテーションを書きたくないため、APIゲートウェイを導入しそこでサーキットブレーカーを設定

    • 各チームの作業コストは0
  • Zuul2の開発は停滞中。yamlで定義がかけるSpringCloudGatewayが開発進行中

  • サービスディスカバリーは使わず、Cloud FoundryのRouterを利用

    • Cloud FoundryではLB→ルーター→サービスという流れになるので、パフォーマンスを気にする場合はサービスディスカバリーを導入すべき
  • サービスディスカバリーの種類

    • 名前解決:DNS、REST
    • 提供方法:アプリ、プラットフォーム
    • EurekaはREST、アプリ
    • ConsulはDNS、アプリ
    • k8sはDNS、プラットフォーム
  • CloudFoundryもサービスディスカバリーをプラットフォームで提供する予定

    • アプリケーション側ではなく、プラットフォーム側でやるべき
  • 最近はEnvoyがホット

    • サービスメッシュを形成する
    • メッシュを管理するIstioもホット

envoyproxy.github.io

istio.io

  • APIでクラスを共有すると、サービス側の変更でクライアントも影響を受けるので、サービス側がクライアントを提供する

    • 破壊的変更がない限りは影響なし
  • k8sやCloudFoundryのようなXaaSを利用する

    • k8sはコンテナから先を実装するCaaS
    • CloudFoundryはコンテナやランタイム/ミドルウェアまでをプラットフォームが提供
  • Spring Bootはコンテナにする利点があまりないのでCloud Foundry

    • コンテナにしてもjava -jarをするだけ
  • CI/CDのパイプラインはconcourse

重要なこと

  • やりたいこと(これまでできなかったこと)が解決できているか
  • 技術を目的にしない

俺のマイクロサービス

  • マイクロサービスは目指すものではなく結果論
  • マイクロサービスには守破離の守がなく、こうやれば始められるというものがない

ECサイトの例

  • もともとはオフショアで作られたシステムで品質がひどい
  • HTML5+Java APIで作り直した

    • 既存システムに比べて安定したが問題も
  • APIが画面項目とひも付き、再利用できない

  • RDBの負荷が高い
  • Tomcatを再起動するとセッションが初期化されるため、誰もアクセスして来ないであろう深夜にしかリリースできない
  • 非同期処理がやっつけ

15のやったこと

1.SpringBootの導入

2.サービスディスカバリーとロードバランス

  • Eurekaを導入。サービスメッシュは検討中

3.キューイング

  • ファイルでやってたところを、オープンな仕様のAMQP(RabbitMQ)を導入
  • 今ならSpringCloudStreamとkafka使うかも

4.セッションレプリケーション

  • SpringSession+Hazelcastを利用。今の所は問題ないが、ヘビーに使い込んでないので、後ほど再評価したい

5.Versioned Platform

  • Sprong+Javaで統一し、親Pomを各サービスで共有

6.shared interface

  • 共通のインターフェースを提供し、コンパイルエラーで気付けるようにする
  • 便利だったけどMSAっぽくないと言われる

7.client library

  • 6はコンシューマーでインターフェースを実装しなければならず、同じコードがたくさんできて効率悪い
  • 実装したクライアントをサービス側で配布。コンシューマー側の実装が楽に。

8.service unit test

  • 各マイクロサービスは、Controllerに対してJunitテストを書く(必須)
    • 別サービスの呼び出しはモックにする。Mokitoとかつかわず、オーバーライド。
  • 複雑な計算等不安な部分は局所的に書く(任意)
  • Http通信の部分はSpringbootを利用
    • 正常系、異常系のJSONやバリデーションをテスト

9.Service integration test

  • サービス結合で期待したデータと違う等のインターフェース齟齬が発生し試験が進まなかった。
  • 複数のマイクロサービスを手動で立ち上げてテストする
    • 実行をjunitにしておけば残しておける
    • 数ケースだけでもかなり問題が検出できる(それくらいインターフェース齟齬が多かった)

10.CI/CD

  • AnsibleとJenkinsを利用して環境構築を自動化
  • APIのバージョニングをしていなかったので困っている。バージョニングはすごく重要

11.monitoring

  • 障害がユーザーからの問い合わせで発覚することが多く監視が必要
  • elasticsearchをつかって全サーバーのCPU、メモリ使用率、ディスク使用率やログを採取
  • ログは5分間でてないと異常と判断
    • 既存メッセージを取り除いて、未知のメッセージが出ているか調べる
  • 気づかれなければいいで片付けない。

12.Frontend service & backend service

  • 再利用できるバックエンド、再利用しない前提のフロント

13.serverless

  • AWS LambdaをPythonで利用
  • バッチや非同期処理で使っている。APIでは使ってない

14.separated data store

  • RDBMSだと1つのJSONを保存するのに8個のテーブルを更新しないと行けないばあいがある
  • 使いやすいKVSを探しているが見つからない

15.イベントソーシング

  • 買い物かごのAPIを、データベース視点のCRUDや追加・削除のようなビジネスロジック的なAPIではなくイベントを登録するAPIだけ提供

    • 商品を入れる、出すを全てイベントとして記録する。
  • データ不整合が発生しても、イベントなら何が原因かがトレースできる

  • 処理の追い越しや不正な遷移が発生したときの対応は検討が必要

これからやりたこと

  • サーキットブレーカー、リアクティブAPI、コンテナやプラットフォーム

感想とか

  • 手段を目的にしないことが大事

  • 自然と教科書の構成に近づいていく

    • 教科書的な構成に合わせなくてもいい
    • 自然と似てくる
  • サービスメッシュとか知らない言葉が増えてたので、常にトレースしていくのが重要

JSUGからのお知らせ

  • 11/24にSpringFest2017

    • 会場は両国KFCホール
    • 前回と同じく400〜500人の規模を想定
  • 来月の勉強会は10/27。会場は恵比寿のRedhat

JJUG CCC 2016 FALLに行ってきた

秋・・・というツッコミはさておき、2年ぶりにJJUG CCCに行ってきました。 感想は順不同で印象に残ったものから。

懇親会は出たかったけど、風邪がヤバイことになっていたのでパス・・・。

リンク

エンジニアの生き方的セッション感想

日本でも出来る!最先端のDevOpsを導入する方法

DevOpsというコール・アンド・レスポンスから始まったセッション。 DevOpsについての非常に熱くそして濃密なセッションでした。

  • 人・プロセス・プロダクトのどれかが欠けてもダメ。
    ものすごいオートメーションを実現しても、リリースに誰かの承認が必要という人の面が欠ければ1日10回デプロイは絶対無理。

  • 頑張って時間をかけて準備しても、本番にデプロイしたら誰も使ってくれないことだってある。
    本番はフィードバックを貰う場所。
    未来は予見できないから、フィードバックから学ぶ。

  • マイクロサービスに入社して上司に指示を受けたことがない。ただ「ハッピーか?」と聞かれるだけ。
    ハッピーでないのであれば、その問題を一緒に解決してくれる。
    上にお伺いを立てないからスピートが上がる。

  • 日本は106カ国で一番アジャイル導入が難しい国。
    でも、アジャイルの土台にはトヨタ方式や守破離という日本文化がある。
    その隙間を埋めているのは西洋文化。
    彼らの思考パターンを理解することが重要。

  • 日本の生産性が低いのはUSが優秀なわけじゃない。
    USは予定されたタスクのうち、大事なことしかやらない。
    タスクのうち、無駄なものは計画的に捨てる。 日本は全部やろうとする。
    差し迫ったものから、重要かどうかに関わらずをやる。
    結果として何もかも中途半端になりやすい。

  • 準備に対する考え方。
    知らなくてもやってみる。やってから考える。
    ソフトウェアの世界で、やってみる前にすべてに備えておくのは難しい。 とりあえずやってみて、やっている間にバリューを見つけ出す。

別に海外がみんなこうだとは思わないし、日本にだってすごいチームはある。
でも、ツールや外側だけを一生懸命取り込もうとしたり、自分たちの組織を変えずにアレンジとかいう体のいい言葉で逃げるのは意味が無い。 考え方を変えないといけないときに来ていると実感。

自分の場合、「とりあえずやってみて、やってる間にバリューを見つける」は欠けてると思う。
色々勉強してきたことからから来る変な思い込みというか見切り。
「やらなくても何となくわかった気になってしまう」というのは悪い癖だと思うので変えていかないと・・・。

JAX-RS REST Client で Cognitive Service や Excel を操作しよう

セッション最初に流れた、ITが目の見えない人をサポートしているビデオ。
ビデオが終わった後、寺田さんが言った「ITサービスが人の役に立つと本当に実感出来るようになった」
これが全てだと思う。

Be a great engineer!〜 フォローすべきトレンド、スルーすべきトレンドをどう見抜くのか

起こっていることを本当に理解しているか?
どのトレンドをフォローし、スルーすべきか。

午後のDevOpsのセッションと組み合わせて考えるとより素晴らしいかも。
いくら「とりあえずやってみる」でも時間は有限。
全部の技術を試すわけには行かない。

技術的なセッション

詳細はスライドにあるので感想をば・・・。

Selenideを試行錯誤しながら実践するブラウザ自動テスト

WebDriverを使いやすくラップしたフレームワーク
Codeboneというエストニアの会社が開発。

Jqueryの$ファンクションでエレメントを指定できたり、Ajaxアサーションを楽に書けたりと、テストが非常に書きやすくなっている。
テスト失敗時に自動でスクリーンショットとHTMLを保存してくれるのはいいと思う。

Payara Micro の設計と実装

Payara Microの仕組みに特化したセッション。 以前、一度試したことがあったのでスムーズに聞けた。

Java EEのマイクロプロファイルがどういう形式になるか分からないけど、Payara MicroはGlassfish使った事ある身としては入りやすい。

Java EE - What's Next?

Java EEの方向性の話。
今までのJava EEがやってきたように、マイクロサービスにおける標準規格を作っていきたい。

「そんなこと実現出来るのかー?」と言うのが今のところの感想。
Java EEと同じやり方であれば、規格に合わせて各ベンダーがミドルウェア出すわけだけど、マイクロサービスまで含めたミドルウェアなんて製品に出来るのか・・・?
クラウドベンダーの依存も何らか発生しそうだし。

あと、Java EE 9の参照実装についてGlassfishってハッキリ言わなかったのも気になる。 それでもマイクロプロファイルは期待。

Kotlin/Go言語デベロッパーミーティング「ライトウェイト言語で行こう!」に行ってきた


kokucheese.com

大井町きゅりあん大ホール(1000人収容!!)という会場で開催されたイベント行ってきました。
平日午後ということもあり、人はそこそこ。

KotlinとGo言語の本をそれぞれ3000円で買えるという特典付きでした。
値下げした分、無駄なもの省いているのか分厚い本2冊を手渡し。
手提げ紙袋(最悪ビニールでも・・・)が欲しかった・・・。

Androidが生み出す開発言語の多様性

発表資料

ownCloud

概要

Androidの生まれるまでの歴史。
技術的要因で発生していた既得権をオープンにするのがイノベーション
2010年付近でのWebの進化の速度に比べ、進歩が停滞していたところにAndroidをリリース。
それによって、キャリア等の既得権だったモバイルがオープンになった。
副産物で訴訟問題とか起きたけど。

Android開発者はGoogle好き。
Googleが何かやると喜んで受け入れられる。
レガシーのものでもGoogleが取り上げると受け入れられる。(本当かいな・・・)

LLVMについてはまだこれから。
将来的にはAndroidを開発できる言語の選択肢が増えるかも。

感想

JJUGナイトセミナーとかでJava側での事情を聞いたけど、Googleのやり方は仕方なかった面もあるかなと。
JCPスマホもサポートするJava SE提案しても、通らなさそうだし。
通ったとしてもリリースまで時間もかかりそうだし。(2011年7月のJava7にはきっと間に合わない)
かといって、新しく言語作るほど時間もなし。

Googleのやり方である、先にリリースしてそこから標準にしましょう的なところは現実的だとは思う。
仕様をみんなで決めてからというJCPのやり方は、Googleにすれば遅すぎて我慢できないのかもしれない。
Androidオープンにしたせいで亜種が乱立して統制取れなくなったのは間抜けだけど。。。

JavaからKotlinに乗り換えるはじめの一歩

発表資料

ownCloud

概要

JetBrainがリリースしたKotlinの紹介。
KotlinはJavaの欠点である冗長さやNull問題を解決してくれる。
Javaで何十行も書かなければいけなかったコードが、わずか3行で書けたりもする。
Android対応も公式が強烈にプッシュしているので使えるようになっておいても損はない。

感想

ことりん可愛いよ、ことりん。

Lombokとかで解決されてきているとはいえ、Javaのダメなところを見事に救済している感じ。
KotlinからJavaの呼び出しも可能なので、過去の資産やJavaの便利なライブラリを使うことも可能。
逆にJavaからKotlinの呼出しはハマリポイントが多いらしいので、フレームワークから使うのはコツがいるかも。

気になったのはJava6のバイトコードが生成されるということ。
Android向けだからだと思うけど、Indyとか使えたらもう少し効率あがりそうなので残念。

あ、ビルド含めるとKotlin・Java・Groovyと3つの言語が必要っていうのはなんか面白い。

Googleが作ったGo言語の力量を見極める!

発表資料

ownCloud

概要


Google謹製のGo言語。
あのDockerでも採用されている。
JVMのような実行環境を持たず、動作する環境を設定してからのクロスコンパイルでバイトコードを生成する。
gRPCのような最新のRPCに対応していたり、RaspberryPiのGPIOのコードも書けたりと使える範囲は広い。

あとはHTTP/2、gRPC、QUICという新しいプロトコルの紹介。

感想

Javaに比べればCに近い印象。(まぁ、開発者にCを作った人いますし)
JVMのようなオーバーヘッドがない分、軽量かつ高速に動きそう。
どちらかというと、Javaよりも低レベルな処理を書くのに向いているように思えた。
低レベルな処理が多めで速度欲しいけど、クラウドでCやC++はちょっとっていうところに使うといいのかな。

プロトコルいついてはQUICは初めて聞いた。
gRPCは使っては見たいけど、Goが前提っぽいのとメッセージがバイナリなのが気になるところ。

残念ながらゴーファーくんはあまり出てこなかった。

Java Day Tokyo2016の不満点まとめ

ちょっと書かざるをえない

運営的なもの

  • 会場が色々な意味で狭い
    • 部屋のキャパシティが小さい?
    • 座席が狭い
    • 展示ブースが狭すぎ。せめて、机と椅子くらい用意してあげようよ・・・。スポンサーの富士通NECさんの扱いが酷すぎない?
    • トイレが少ない
  • 展示をもう少し充実させて欲しい
    • スポンサーや企業のデモを見るのも楽しいのに。。。
    • Dukeくんと記念撮影もなかったし
    • そのくせ物販だけは例年通りやってるし
  • 寒かった
  • セッション資料の公開はアナウンスして欲しい
    • スライド切り替わる度にシャッター音がウザい!!
  • 机がないのはまぁいいとしても椅子が辛い・・・。
    • 2時間で終わるナイトセミナーとかならともかく、1日座って聴くのには辛い
    • 品川プリンスの椅子は良かったw
  • ストリーミングが気がついたら終わってた?
    • 終わったならアナウンスだそうよー

まぁ、一昨年去年に比べて、予算を大幅に削られてるなぁとは思いました。
スタッフも少なめな気もしました。
来年もちょっと不安・・・。

良かった点

  • セッション入場前にバーコード読み取りなくなったので、スムーズに入れて良かったかも
    • その代わり予約が全く機能してなかった気もする
    • 単純に参加者ごとにカード作る手間にお金を使えなかっただけかもしれないけど:P

JAVAのおじさん

業務サボるために来てるとしか思えないオジさんはどうにかできないものかね。。。

  • セッション中寝てる
    • 専門的な話は難しい、仕方ないよね
  • セッション中にツムツムしてる
    • お仕事の話よりゲームのほうが面白い、仕方ないね

Java Day Tokyo2016に行ってきたよ

都合のため、キーノートとナイトセッションは参加できず。
午後の5セッションの感想です。
スライドがアップされたら更新するかも

Introduction to MVC 1.0

Java EE 8に含まれるMVC1.0の概要の説明。
深く突っ込んだ内容はなし。
MVCとは?」の説明からなので、基本的なところから学べた。

そうは言いつつも、さりげなくViewでFreeMaker使ってるサンプルがスライドに入ってたり。

実装はOzark。
仕様はそれほど難しくなく、JAX-RSを使いこなせてる人ならそのまま使えそうな感じ。
SpringMVC慣れてる人も大丈夫そう。
感想としては、Viewの指定方法が沢山あるのは使う時に迷いそうなのが微妙。

まとめにもあったけど、Java EEMVCという選択肢が増えるのは良いことであるのは間違いない。
ただ・・・遅すぎない?
EE7に入っていればよかったのに・・・。

Java EE 7 アプリケーションとWebセキュリティ

スーツ姿の裏紙さんセッション。
IPAが公開している、安全なWebサイトの作り方をJava EEでどう実現するかの話。

重要なこと

  • 最初からセキュアなコードを書くこと。セキュアじゃないコードをセキュアにするのはコストが高い
  • 対策も必要だけど、脆弱なコードをチェックする仕組みも必要
  • それぞれの対策は簡単だけど、攻撃がどういう仕組みでどういう理由で対策できるのかを知らないと対策しても不安が残る
  • セキュリティに関する資料は一般的に多く出回っているので、普段から勉強しておくのが大事
  • ビジネスロジック(モデル)で対応するのは、可読性や保守性に悪影響。なるべくViewやControllerで対応する

各攻撃に対する対策

JSPや低レベルな処理の話もあったけど、面倒なので割愛。JSFを使おう。

XSS

Faceletならデフォルトで対策済。

CSRF

JSFなら対策不要。
ただしViewをステートレスにすると対策が必要になる。
ステートレスとステートフルを使い分けるといい。

SQLインジェクション

JPAの@NamedQueryアノテーションを使う。
em.createQueryはクエリ文字列を受け取るため、SQLインジェクション脆弱性があるクエリを指定される可能性がある。
CriteriaAPIを使う手もあるが、学習コストが高いのでオススメはしない。

パスのパラメーターチェック

JavaのFileAPIをそのまま使うのではなく、パラメータチェックを行うラップAPIを作成して利用する。
こうすることで、FileAPIで検索して脆弱なところを検出できる。

クリックジャッキング

レスポンスヘッダーに、X-Frame-Optionsをつけることでiframe、frameを禁止できる。
ただし、Ajaxで行うファイルアップロードも潰してしまう可能性があるので、すべて禁止するのではなくSameOrigin指定を推奨する。

OSコマンドインジェクション、バッファーオーバーフロー

割愛。
どちらも普通に作っていれば起こらない。

その他

レスポンスヘッダーに以下の二つをつけるといい。

  • X-Content-Type-Options:nosniff
    IEはコンテントタイプが指定されていないものを自動で判断する。
    そのため、悪意のあるコンテンツを解析した際にスクリプトを実行される可能性がある。
    このヘッダーをつければ自動解析を無効にできる。

  • Content-Sequrity-Policy 最強のCSRF対策だけど、CSSやイメージを妨げる可能性あり。
    すべて禁止ではなく、許容するリソースを指定する。

Java Concurrency A(nother) Peek the Hood

Javaの並行処理に関する話。
わかりやすかったけど、技術的にはかなり深い所。

概要

  • Webアプリケーション、GUIはマルチスレッドが普通
  • ライブラリを公開する場合も、マルチスレッドで使われることを考慮しよう
  • というより、シングルスレッドが許されるのは学校の宿題まで

  • ConcurrentAPIとか使い方を暗記していても仕組みを理解してないのは危険

  • メモリモデルを正しく理解しよう

  • 予期しない動きをする犯人は、JITコンパイラとメモリオーダリング

    • コンパイラの最適化は、開発者がわからない
    • 同じコードでも、JREがServerとClientで動きが異なるケースがある
    • メモリオーダリングはCPUによって仕様が異なる。Intel、Sparkは厳密。ARMは少しゆるい。
  • マルチスレッドの場合、各スレッドによって実行順の基準が異なる

  • Javaの場合はHappened-before

  • Java SE 5まではfinalがイミュータブルではなかった

  • 並列処理ライブラリを利用するときは、なるべく抽象化されているものを使う。具体的な処理を利用すると実行効率が良さそうに思えるが、とても難しく問題も出やすい。

  • 本番と同じ環境でテストすることが大事

  • 本を読むならJava Concurrency in Practiceがおすすめ

実践してわかったJavaマイクロサービス開発

モノリシックなWebアプリケーションをマイクロサービスに変えていった経験の話。
マイクロサービスは技術的な話は多いけど、実践例は少なかったので参考になった。
スライドが丁寧だったので、内容の詳細は省略。

参考になった点

  • サービスディスカバリーは必須
  • クライアントとサービスを共通のインターフェースにすることで、IF仕様書を作らなくて良くなる
  • 多言語化はEurekaとの関係もあり難しい
  • サーキットブレーカーは障害が起きたらどうすればいいかまだわからない
  • HTTPは同期処理。AMQPは戻り値なしの非同期
  • 画面を中心にAPIを考えると、巨大なものになりやすい
  • ドメイン分割は大事。ドメインごとにサービスを作るくらいがちょうどいい

Javaエンジニアのためのクラウド時代の過ごし方

これもスライドがとてもいい感じなのでポイントだけ。
決してお酒が回って面倒なわけではない。

考えさせられた点

  • 今までは作ることが大変だった。しかし今は作るところは簡単になり、運用面の問題に向かい合えるようになった。
  • 良いコードを書くことは大事だけどそれだけじゃダメ
  • アジャイルクラウド、DevOPS、マイクロサービスは、それぞれの組織が取り組んできた結果
  • クラウドによって、ハードウェアがソフトウェアとして定義できる
    • 自動化、コピーができる
    • 非機能要件のテストが書ける
  • PaaSは稼働しているミドルウェアを借りるイメージ
    • 制約はあるが、使うことで便利になる
    • 個々の問題に対するミドルウェアを簡単に調達できる
    • オンプレで作ったものをIaaSに移行するのは非効率でクラウドの利点を生かせない
  • インフラのテストは本番環境でしかできない。そのテストをするのがNetflixのカオスモンキー
    • カオスモンキーはランダムにサービスをダウンさせる
    • カオスゴリラはAZを丸ごとダウンさせる
    • カオスキングコングはリージョン丸ごとダウン
  • ダウンの目的は自動で復旧するかの確認。手順書ではなくコード。運用を不要にする。

これからのエンジニア

2つのどちらかにならないといけない

  • 専門家
  • ゼネラリスト
    • テクノロジー以外の分野とのバランス
    • 最低でも技術と業務を両方見れる

JSUG勉強会 2016年その3.5に行ってきました

イベントページはこちら

JSUG勉強会 2016年その3.5 - Kenny Bastani来日特別講演 - 日本Springユーザ会 | Doorkeeper

SpringBootを中心とした、マイクロサービスについてのセッション。
テーマ自体が難しいことに加えて、QAを含めて通訳なし100%英語というハードコアなセッションでしたが、ためになるお話でした。

最大の敵は開始前のピザとビール・・

セッション概要

  • 開始前の会場アンケート。 SpringBoot使ってる人はたくさん挙手があった。
    逆にSpringCloudを使ってる人はほぼいなかった。

  • ApacheTomcatMySQLで構成されるモノリシックなアプリケーションから、SOAを経てマイクロサービスになる。
    マイクロサービスは、各サービスで共有するShered Cacheとそれぞれのサービスの特性に応じたDBMS等のリソース。
    サービスごとにリソースを分けることで、1つのサービスがダウンしても全体はダウンしない。

  • インフラストラクチャもスケールアウトが難しいモノリスな構成から、スケールアウトが容易なコンテナへ。
    マイクロサービスはコンテナ単位で依存関係を持つ。 依存関係の解決はServiceDiscoveryがおこなう。

  • SpringBootのMavenダウンロード数は、2015年12月に225万を突破

  • SpringBootは「フレームワークのためのフレームワーク
    SpringFrameworkがケーキの材料だとしたら、SpringBootは完成したケーキ。 ケーキを作成するキッチンがSpringInitializr。 SpringBootがケーキだとしたら、SpringCloudはケーキが並んだショーケース。

デモ

マイクロサービスで構築したショッピングサイト。
ソースは↓。

github.com

  • 何がすごいって、モノリシックな普通のWebアプリケーションにしか見えないくらいサクサク動く
    しかも動いているだけじゃなく、メトリクスもキチンと取っている。
    「WebAPIを使いまくると遅い」と決めつけるのは間違いだった。

  • ソースはまだあまり見てないけど、サービスの単位は思っていたよりも小さい

  • ただ、メモリは全体で8.5GBくらい使っているっぽい
    モノリシックに比べれば、大きくなりそう

Q&A

QAもほとんど英語。
あまり聞き取れなかった。。。

質問の傾向としては、マイクロサービス構築時のベストプラクティスやガイドラインについて聞いているのが印象に残った。
回答としては、ケース・バイ・ケースと言った感じ?

反省点

  • やっぱり終わる前にお酒を飲んではいけない。
    後半はマッタリしてしまった・・・。

  • 英語で質問出来るようにならないとまずいなぁ・・・。

  • 他の人の質問を聞いてて思ったことは、最初に質問内容をバーンと言ってから、細かい事情や背景を説明したほうが良さそう。
    詳細を先に話し始めると、説明が難しくてそこで詰まってしまう。
    聞いてる方もどこから質問なのか判別が難しくなりそう。

  • 今年度(not 今年)は勉強会に行ったらブログを書く。

いじょ!