JavaOne 2017 報告会へ行ってきた
ようやく風邪から治ったので初投稿です。
Javaの方向性
Javaのキーワードにnimbleが新しく追加。
nimbleは軽量、素早さ。
ITの変化の速さに対応していく。
Javaのリリースについて
まず、OracleJDKとOpenJDKの技術差を1年かけてなくす。
ソースコードは一本化。
OpenJDKは6ヶ月ごとのリリース。
LTSはなしで、6ヶ月ごとに最新版にアップデートして使う。
OracleJDKと技術的な差分がないバイナリ配布。
OracleJDKの無償版は18.3まで。
18.9以降は3年ごとに8年間のLTSがある有償版。
http://www.oracle.com/technetwork/jp/java/eol-135779-ja.html
次の機能リリースであるJava SE 18.3スケジュールや追加される機能は
http://openjdk.java.net/projects/jdk/18.3/
Java EE
間違えやすいけど、EE4Jは移管プロジェクト名。
ブランド名はこれから決める。
速度が落ちるのでJCPのような仕様策定の標準化はしないけど、JSRのような仕組みは取り入れる予定。
OracleはJava EEサポートに関する既存のベンダー(日本だとNECや富士通とか)との契約は尊重。
ライセンスやJava EEの認定も引き続きサポート。
Java EE 8は2025年まではサポートするので、ベンダーはその間にEE4Jへの移行方針を決めてほしい。
その他
IntelがPM(Persistent Memory)に合わせてJavaに力を入れている。
PMはDRAMより大容量で価格が安い代わりに速度は遅い。
Javaでは揮発するヒープとしても、永続化先としても使える。
揮発するヒープとしての用途はビッグデータやインメモリDBのような大容量を使うアプリ。
マイクロサービス関連は細かい実装よりも取り組んだ事例や組織面のセッションが多かったらしい。
フレームワークやライブラリは自前で開発したりラッピングするものではなく、consumeするもの。
それよりも、「サービス」という部品をどう協調させていくかが重要。
コミュニティ関連やフォトセッション、LTは非常に面白かった。
ただ、写真で見るのと現地に行ってその場の空気を感じるのは大きく違うと思うので、機会があれば是非行きたい。
Mackerel / NewRelic / Elasticsearch Seminarに行ってきた
奇跡の二日連続更新なので初投稿です。 モニタリングをテーマに、3つのツールの違いがよくわかるセミナーでした。
ご挨拶
モニタリングをしていないとサービスが動作しているかもわからない.
十分な考慮の元で設計されたモニタリングインフラストラクチャが重要.
十分な考慮＝ビジネスの特性等を把握.
Linux OSから見るMackerelのパフォーマンスモニタリング
何を見ればいいかわからない
グラフを見てもどこが悪いかわからない
そんな人向けのLinuxのモニタリング
Mackerelの特徴
利用には、サーバーにMackerelエージェントをインストールだけ。エージェントからMackerelのSaaSにHTTPSで送信。
- 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言語に対応
遅いトランザクションや直近のアラートが観れる
- アラートは集中管理。通知チャネルや設定条件が豊富
ダイナミックベースラインアラート
- 普段の振る舞いと違った動作をしたらアラート。機械学習で過去の傾向を分析
内部サービスの呼び出し階層が観れる
- 一覧で赤いとアラートが発生している
インストール後にアラート設定とユーザー満足度（平均レスポンスタイム）の閾値を設定することを推奨
デプロイトラッキングで、トラブルが多いデプロイしたタイミングを監視できる
- デプロイ前後のパフォーマンスが比較
- デプロイした時刻が残るので調査に役立つ
応用編
ソースコードを修正することで、さらなる情報取得が可能
カスタム属性
- 例えばECサイトのマルチテナントでショップIDをカスタム属性として追加
- ショップごとにパフォーマンス追跡が可能
- 入れない場合、アプリ全体でしか見れない
カスタム計測
- メソッドに指定することでトランザクションのトレースをより詳細に見るために必要
まとめ
-
- パフォーマンスに売り上げに繋がるサービスで多く採用
ブラウザの監視も可能。アプリケーションの監視と組み合わせ、1つのダッシュボードで観れる
最新動向としては、AIに注力
- 過去のデータから今後パフォーマンスで問題になりそうな情報と対策を提供
NewRelicを導入して開発とインフラのコミュニケーションが改善
- インフラチームが最初に障害に気がついたとき、エビデンスを持ってコミュニケーションできる
- 開発もパフォーマンスに対する意識が高くなった
Elastic Stackによるログの監視入門
ElasticStackは100％OSSで有償サポート
ELKにBeatsというOSSが追加された.
バージョンを5.0で全部統一
昔はバージョンが揃ってなかったので、間違った組み合わせで使って「動かない」というissueが乱立
Beat
- Go言語エージェント。
- データがあるところに仕込むと取り出してくれる
- 送り先はSearchかLogstsh
- File、メトリクス、ネットワーク、Windowsイベントログ、パケット、そのほかにも色々
Logstash
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の仕組みを利用
リンクのURLはSpringCloudConfigで一括管理
- 開発中とプロダクションで値の切替もできる
他のサービスと連携する部分はAPI
API呼び出しで障害が発生すると、障害の連鎖で最悪LBがダウンする
- 障害の連鎖を防ぐためのサーキットブレーカー（Hystrix）の導入
- Fallbackが注目されがちだが、障害の発生したAPIにアクセスさせないことが重要な目的
各APIにHystrixのアノテーションを書きたくないため、APIゲートウェイを導入しそこでサーキットブレーカーを設定
- 各チームの作業コストは0
Zuul2の開発は停滞中。yamlで定義がかけるSpringCloudGatewayが開発進行中
サービスディスカバリーは使わず、Cloud FoundryのRouterを利用
サービスディスカバリーの種類
CloudFoundryもサービスディスカバリーをプラットフォームで提供する予定
- アプリケーション側ではなく、プラットフォーム側でやるべき
最近はEnvoyがホット
- サービスメッシュを形成する
- メッシュを管理するIstioもホット
APIでクラスを共有すると、サービス側の変更でクライアントも影響を受けるので、サービス側がクライアントを提供する
- 破壊的変更がない限りは影響なし
k8sやCloudFoundryのようなXaaSを利用する
- k8sはコンテナから先を実装するCaaS
- CloudFoundryはコンテナやランタイム/ミドルウェアまでをプラットフォームが提供
Spring Bootはコンテナにする利点があまりないのでCloud Foundry
- コンテナにしてもjava -jarをするだけ
CI/CDのパイプラインはconcourse
- Concourse: CI that scales with your project
- Yamlで定義でき、1チームが作成した後コピペで増やせる
重要なこと
- やりたいこと(これまでできなかったこと)が解決できているか
- 技術を目的にしない
俺のマイクロサービス
- マイクロサービスは目指すものではなく結果論
- マイクロサービスには守破離の守がなく、こうやれば始められるというものがない
ECサイトの例
- もともとはオフショアで作られたシステムで品質がひどい
-
- 既存システムに比べて安定したが問題も
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
14.separated data store
15.イベントソーシング
買い物かごのAPIを、データベース視点のCRUDや追加・削除のようなビジネスロジック的なAPIではなくイベントを登録するAPIだけ提供
- 商品を入れる、出すを全てイベントとして記録する。
データ不整合が発生しても、イベントなら何が原因かがトレースできる
- 処理の追い越しや不正な遷移が発生したときの対応は検討が必要
これからやりたこと
- サーキットブレーカー、リアクティブAPI、コンテナやプラットフォーム
感想とか
手段を目的にしないことが大事
自然と教科書の構成に近づいていく
- 教科書的な構成に合わせなくてもいい
- 自然と似てくる
サービスメッシュとか知らない言葉が増えてたので、常にトレースしていくのが重要
JSUGからのお知らせ
11/24にSpringFest2017
- 会場は両国KFCホール
- 前回と同じく400〜500人の規模を想定
来月の勉強会は10/27。会場は恵比寿のRedhat
JJUG CCC 2016 FALLに行ってきた
秋・・・というツッコミはさておき、2年ぶりにJJUG CCCに行ってきました。 感想は順不同で印象に残ったものから。
懇親会は出たかったけど、風邪がヤバイことになっていたのでパス・・・。
リンク
公式ページ
JJUG CCC 2016 Fallスライドとかのまとめ
GitHub - jjug-ccc/slides-articles-2016fall: JJUG CCC 2016 Fallの発表資料およびブログ記事まとめ
エンジニアの生き方的セッション感想
日本でも出来る！最先端の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言語デベロッパーミーティング「ライトウェイト言語で行こう！」に行ってきた
大井町きゅりあん大ホール（1000人収容！！）という会場で開催されたイベント行ってきました。
平日午後ということもあり、人はそこそこ。
KotlinとGo言語の本をそれぞれ3000円で買えるという特典付きでした。
値下げした分、無駄なもの省いているのか分厚い本２冊を手渡し。
手提げ紙袋（最悪ビニールでも・・・）が欲しかった・・・。
Androidが生み出す開発言語の多様性
発表資料
概要
Androidの生まれるまでの歴史。
技術的要因で発生していた既得権をオープンにするのがイノベーション。
2010年付近でのWebの進化の速度に比べ、進歩が停滞していたところにAndroidをリリース。
それによって、キャリア等の既得権だったモバイルがオープンになった。
副産物で訴訟問題とか起きたけど。
Android開発者はGoogle好き。
Googleが何かやると喜んで受け入れられる。
レガシーのものでもGoogleが取り上げると受け入れられる。（本当かいな・・・）
感想
JJUGナイトセミナーとかでJava側での事情を聞いたけど、Googleのやり方は仕方なかった面もあるかなと。
JCPでスマホもサポートするJava SE提案しても、通らなさそうだし。
通ったとしてもリリースまで時間もかかりそうだし。(2011年7月のJava7にはきっと間に合わない)
かといって、新しく言語作るほど時間もなし。
Googleのやり方である、先にリリースしてそこから標準にしましょう的なところは現実的だとは思う。
仕様をみんなで決めてからというJCPのやり方は、Googleにすれば遅すぎて我慢できないのかもしれない。
Androidオープンにしたせいで亜種が乱立して統制取れなくなったのは間抜けだけど。。。
JavaからKotlinに乗り換えるはじめの一歩
発表資料
概要
JetBrainがリリースしたKotlinの紹介。
KotlinはJavaの欠点である冗長さやNull問題を解決してくれる。
Javaで何十行も書かなければいけなかったコードが、わずか３行で書けたりもする。
Android対応も公式が強烈にプッシュしているので使えるようになっておいても損はない。
感想
ことりん可愛いよ、ことりん。
Lombokとかで解決されてきているとはいえ、Javaのダメなところを見事に救済している感じ。
KotlinからJavaの呼び出しも可能なので、過去の資産やJavaの便利なライブラリを使うことも可能。
逆にJavaからKotlinの呼出しはハマリポイントが多いらしいので、フレームワークから使うのはコツがいるかも。
気になったのはJava6のバイトコードが生成されるということ。
Android向けだからだと思うけど、Indyとか使えたらもう少し効率あがりそうなので残念。
あ、ビルド含めるとKotlin・Java・Groovyと３つの言語が必要っていうのはなんか面白い。
Java Day Tokyo2016の不満点まとめ
ちょっと書かざるをえない
運営的なもの
- 会場が色々な意味で狭い
- 展示をもう少し充実させて欲しい
- スポンサーや企業のデモを見るのも楽しいのに。。。
- Dukeくんと記念撮影もなかったし
そのくせ物販だけは例年通りやってるし
- 寒かった
- セッション資料の公開はアナウンスして欲しい
- スライド切り替わる度にシャッター音がウザい！！
- 机がないのはまぁいいとしても椅子が辛い・・・。
- ２時間で終わるナイトセミナーとかならともかく、1日座って聴くのには辛い
- 品川プリンスの椅子は良かったw
- ストリーミングが気がついたら終わってた？
- 終わったならアナウンスだそうよー
まぁ、一昨年去年に比べて、予算を大幅に削られてるなぁとは思いました。
スタッフも少なめな気もしました。
来年もちょっと不安・・・。
良かった点
- セッション入場前にバーコード読み取りなくなったので、スムーズに入れて良かったかも
- その代わり予約が全く機能してなかった気もする
- 単純に参加者ごとにカード作る手間にお金を使えなかっただけかもしれないけど:P
JAVAのおじさん
業務サボるために来てるとしか思えないオジさんはどうにかできないものかね。。。
- セッション中寝てる
- 専門的な話は難しい、仕方ないよね
- セッション中にツムツムしてる
- お仕事の話よりゲームのほうが面白い、仕方ないね
Java Day Tokyo2016に行ってきたよ
都合のため、キーノートとナイトセッションは参加できず。
午後の５セッションの感想です。
スライドがアップされたら更新するかも
Introduction to MVC 1.0
Java EE 8に含まれるMVC1.0の概要の説明。
深く突っ込んだ内容はなし。
「MVCとは？」の説明からなので、基本的なところから学べた。
そうは言いつつも、さりげなくViewでFreeMaker使ってるサンプルがスライドに入ってたり。
実装はOzark。
仕様はそれほど難しくなく、JAX-RSを使いこなせてる人ならそのまま使えそうな感じ。
SpringMVC慣れてる人も大丈夫そう。
感想としては、Viewの指定方法が沢山あるのは使う時に迷いそうなのが微妙。
まとめにもあったけど、Java EEにMVCという選択肢が増えるのは良いことであるのは間違いない。
ただ・・・遅すぎない？
EE７に入っていればよかったのに・・・。
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とか使い方を暗記していても仕組みを理解してないのは危険
メモリモデルを正しく理解しよう
マルチスレッドの場合、各スレッドによって実行順の基準が異なる
Javaの場合はHappened-before
Java SE 5まではfinalがイミュータブルではなかった
並列処理ライブラリを利用するときは、なるべく抽象化されているものを使う。具体的な処理を利用すると実行効率が良さそうに思えるが、とても難しく問題も出やすい。
本番と同じ環境でテストすることが大事
本を読むならJava Concurrency in Practiceがおすすめ
実践してわかったJavaマイクロサービス開発
モノリシックなWebアプリケーションをマイクロサービスに変えていった経験の話。
マイクロサービスは技術的な話は多いけど、実践例は少なかったので参考になった。
スライドが丁寧だったので、内容の詳細は省略。
参考になった点
- サービスディスカバリーは必須
- クライアントとサービスを共通のインターフェースにすることで、IF仕様書を作らなくて良くなる
- 多言語化はEurekaとの関係もあり難しい
- サーキットブレーカーは障害が起きたらどうすればいいかまだわからない
- HTTPは同期処理。AMQPは戻り値なしの非同期
- 画面を中心にAPIを考えると、巨大なものになりやすい
- ドメイン分割は大事。ドメインごとにサービスを作るくらいがちょうどいい
Javaエンジニアのためのクラウド時代の過ごし方
これもスライドがとてもいい感じなのでポイントだけ。
決してお酒が回って面倒なわけではない。
考えさせられた点
- 今までは作ることが大変だった。しかし今は作るところは簡単になり、運用面の問題に向かい合えるようになった。
- 良いコードを書くことは大事だけどそれだけじゃダメ
- アジャイル、クラウド、DevOPS、マイクロサービスは、それぞれの組織が取り組んできた結果
- クラウドによって、ハードウェアがソフトウェアとして定義できる
- 自動化、コピーができる
- 非機能要件のテストが書ける
- PaaSは稼働しているミドルウェアを借りるイメージ
- インフラのテストは本番環境でしかできない。そのテストをするのがNetflixのカオスモンキー
- カオスモンキーはランダムにサービスをダウンさせる
- カオスゴリラはAZを丸ごとダウンさせる
- カオスキングコングはリージョン丸ごとダウン
- ダウンの目的は自動で復旧するかの確認。手順書ではなくコード。運用を不要にする。
これからのエンジニア
２つのどちらかにならないといけない
