2015/09/25

Zabbix Conference 2015@ラトビア最新速報!と、Zabbixだけじゃない、OSSを徹底活用した運用自動化の実現

zabbix3.0のリリース時期は未定です。

【速報!Zabbix最新動向紹介】

@ike_dai さんのお話。
  • ラトビアまで行って参加。
  • 参加者は28カ国、183人(日本人7名)。
    • 国際カンファレンスなのにこじんまりしてますw
●Zabbix3.0
  • リリース時期未定。年内にはなんとか。
    • 新機能はまだbranchesでの開発中。trunkにはマージされていない…
●暗号化
Before
  • 平文で送受信。
  • 送信元IP制限は可能だったが、ログ監視結果/ホスト情報を見せたくない場合はVPN/SSH port forwardingなどで対応。
After
  • TLSv1.2の認証&暗号化。
  • PSK/証明書ベース。
  • OpenSSL、GnuTLS、PolarSSLが使用可能。
    • 暗号化したい部分のみ有効化可能
Passiveの暗号化
  • TLSAccept,,TLSPSKIdentity,TLSPSKFileが設定ファイルに追加される。
Activeの暗号化
  • TLSConnect,TLSPSKIdentity,TLSPSKFileが設定ファイルに追加される。

zabbix_sender,zabbix_getにもこれらに該当するオプションが追加される。

●Zabbix Frontend
MVCモデルでクリアなコードに。
→ページカスタマイズ/追加が楽に。

●Problem&trend prediction
forecast:特定の未来時間に値がどうなるかを評価
timeleft:特定の値に達するまでにあとどれぐらいかを評価

の機能が追加される予定。
  • 線形近似、指数近似、多項式近似、対数近似。累乗近似が使用可能。
    • 近似法は ユーザが指定 する必要がある。
●その他
  • トリガー関数などの閾値にパーセンタイルが使用可能に。
  • SMTP認証に対応
  • ハウスキーピング処理を任意のタイミングで手動実行。
    • zabbix_server -R housekeeper_execute
    • HouseKeepingFrequency=0で自動処理無効化が可能に。

これは地味だがすごく助かる。

  • Top100のフィルタリングが可能。
  • ZabbixUSAができた!
  • ZabbixShareβ公開。テンプレート/活用ソリューションがあるが、現段階では玉石混交。今後の運用は検討中。
●活用ソリューション・事例
zlm-python
  • ローダブルモジュールはC言語で実装されていてハードルが高い。
    • メインはPythonで会って、CからPythonコードを呼び出して組み込めるように。
      ※ローダブルモジュールはスクリプトによる監視に比べて5~10倍速い。
大規模環境のZabbix監視
  • 大規模な環境の場合、Zabbixに対する設定状態のチェックも重要
  • ZabbixのDB情報、CMDBの情報をDWHに集約し、JasperReportでレポート。
  • Zabbix Configuration Checker
    • 設定漏れがないことの監視を効果的に行う事例
globo.comの事例
  • ブラジルの放送局。CloudStackベースの大規模環境監視

zabbix_agentのデバッグ
http://www.slideshare.net/Zabbix/volker-frhlich-how-to-debug-common-agent-issues
このスライドおすすめ。

【Zabbix監視運用業務の自動化事例】

@satoruf さんのお話。

https://tis-oss.doorkeeper.jp/events/24978
で聞いた話のアップデート版

  • 最新のJobScheduler(v1.10)ではユニバーサルエージェントでDocker、RaspberryPiにも対応。
    • 残念ながら有償版のみ
  • HyClops JobMonitoringではバッチ実行時に監視の閾値を変更する、などが可能。

【Zabbixだけじゃない OSSの監視とジョブ管理ーHinemosのご紹介】

  • 監視とジョブをワンパッケージで使えます
  • インストールはコマンド一発。DBも入ります。エージェントも一発で監視/ジョブが使えます
  • 簡単設定

●Zabbixと違うところその①
Hinemosは雰囲気で監視が設定できる。

●Zabbixと違うところその②
「スコープ」と「テンプレート」
  • Hinemosはノードを「スコープ」という単位でグループ化
  • Zabbixは監視設定をグループ化
HinemosはHinemosマネージャとHinemosエージェントを入れれば監視もジョブもすぐ使えます。
  • Zabbix+JobSchdulerは…

Hinemos5.0からジョブのリトライが可能になった。

この方はHinemosWorldでも登壇するので聞きたいが、残念ながらDevSumiとかぶってる…

【Zabbixを徹底活用!~~高度なPostgreSQL監視を実現する pg_monzのご紹介】

PostgreSQLは主に稼働統計情報で監視
  • PostgreSQLのアクティビティ情報を蓄積
  • SELECT文でビューにアクセスして参照
    • pg_stat_activity、pg_stat_databaseなど
  • 主に累積値なので差分から事象を判断する必要がある。
●PostgreSQL専用ツール
pg_statsinfo,pg_stats_reporterが代表だが
  • 専用のリポジトリDBが必要
  • 統合監視ツールとは別に運用する必要がある。
●pg_monzでできること
クラスタとしてのサービス状態監視
  • サーバだけの監視では気づきにくいクラスタ特有の障害に対応
●pg_monzで活用するZabbix機能
  • v1ではAgentのみを利用
  • v2ではAgentとSenderを利用
    • PostgreSQLサーバへの接続とSQL実行回数を削減
  • Zabbixローレベルディスカバリ
    • 環境に合わせた監視設定を自動で生成
    • データベース単位の監視設定、Standbyサーバへのレプリケーション監視設定

ZabbixでPostgreSQLを監視できます。そう、pg_monzならね。

なぜか外人からしかプルリクが来ないという嘆き。

| | コメント (0) | トラックバック (0)

2015/09/15

Cloud Week 2015@Hokkaido University

これに参加するため、札幌へ行ってきました。 一応、主催側の体でちょっとだけ司会なども。

1日目

【『さくらのクラウド』を例にしたパブリッククラウドの作り方】

  • ポータルもVPSのダッシュボードもUIは非常に若い社員が作っています。

【日立の考えるアカデミック分野における最適なクラウドサービス】

日立のクラウドはあまり知らなかったな。
学生/大学向けの視点は他のイベントではなかなか聞けないので面白い。

【デジタルビジネスの世界を支えるプラットフォーム】

10月から一般トライアルを開始するFUJITSU CLOUD SERVICE K5の話。
富士通はスマホから交通費精算ができない、とか、今も紙で契約書作ってますという自虐ネタw

  • 新たなイノベーションが起きても、課金や契約管理は現行システムとつながざるをえない。
    • 既存システムとつなぐシステムの構築
  • "K5"→Knowledge,5大陸をイメージ。グローバルに知見を広げていく。
  • IasS:OpenStackベース
  • PaaS:CloudFoundryにIaaS連携、LaaSを拡張。
    • 今後、マルチAZ、オートスケール、Dedicate,Dockerイメージインポートなどを拡張予定。
  • WL-PKG:運用定義/構成定義/ソフトウェアスタック/テストセットをパッケージ化したもの。
    • マルチクラウドへのデプロイを可能に。

【アカデミックな皆様のお役に立つ AWS最新情報】

http://bit.ly/1K0z775

AWSホワイトペーパーおすすめ。
→HPCのホワイトペーパー出たよ!

【Shibboleth IdPのサービスと認証強化】

http://wisepoint.jp/wpshibboleth.html
のお話。

  • イメ-ジングマトリクス認証
    • 事前に覚えた画像でワンタイムパスワ-ドを生成
  • グループウェア等だけでなく、WebEx、BIG-IPなどとも連携可能。
  • SAML2.0に対応していないものにはリバプロとしてサービス提供も可能。

【ハイブリッドクラウド利活用におけるITリソースの最適化 ~PrimeCloud Controllerによるクラウドマネージメントのアプローチ~】

パブリッククラウド間で自動的にVPN接続する設定も。
http://www.primecloud-controller.org/
オープンソースで提供しているとのことなので、CloudStackと組み合わせて使ってみようかと思った。

【次世代クラウドにおけるネットワークサービスインフラとは】

  • NetScalerだけでなく、他社もLBにモバイル対応の機能を載せてきている。
  • SSL終端がやはり、ハードウェアアプライアンスの強み。
    • 2Uの筐体で80程度のLBは動く。
  • NetScalerSDXで、Paloaltの仮想アプライアンスも動かせる。
    • OpenStackとの連携も始めた。

【ソフトウェア管理や配布を効率化するクラウド製品ご提案】

IT資産管理の必要性。
  • ASSETBASEではWindowsのパッチだけでなく、AdobeやJava、ブラウザのパッチ配信も可能。
    • クラウドサービスとして提供しています。
  • 大学で一番、ウケがいいのは、ソフトウェアのライセンス数管理。
    • 買収された会社、クラウド版、ローカルインストール版なども辞書を使用して正しくライセンス管理が可能。
  • DownloadStationの説明。インストーラをポリシー付きのバイナリとしてラッピング
    • インストール台数
    • インストール期限
    • パスワード設定
      などが可能に。
  • クラウドサービスにしたメリットは学内ネットワークだけでなく、インターネットでも監視可能ということ。(学校の先生は家に持って帰ることが多い…)

【京都大学におけるプライベートクラウド環境の現状と課題】

部局の力が強く、個別に整備されてきた京都大学の情報基盤を「集約と共有」ということで作り替えていくお話。

  • 学生向けのホスティングサービスで、public_htmlの下にwordpress入れて提供とか怖い。
  • 昨今の様々な問題を受け、京都大学では9/1付けで論文、研究データなどをすべて、少なくとも10年間保存する。という通達が出た。
  • 現在、動画配信サービスはあまり活用されていないが、教育の動画はたくさんあるので活用していきたい。

2日目

【アプリケーション中心型オーバーレイクラウド】

  • データ解析プラットホームの構築
    • アプリケーションごとに最適(占有)プラットホームを自動的かつ高速に構築する基盤が必要
    • 現状は2週間~1ヶ月を要している。
  • 仮想ネットワーク
    • SINET5ではバックボーンが100GBps。オンデマンドでL2VPLSを作成可能にしていく。
  • RNA-Seq01のコンテナ対応
    • Dockerでコンテナ化

【クラウドブローキングのための述語論理式によるシステム記述について】

  • ブローカーの3つの仕事
    • 仲介:クラウドサービスを提供する
    • 統合:新たなサービスを提供する
    • 調停:動的にサービスを選択する
  • システムに対する要件(=相互依存した制約条件の集まり)を述語論理式として記述し、システム記述を表す式とする。
  • この式を用いて、クラウドの資源最適化を行うBrokerをフレームワークとして定義していく。

【クラウドバーストバッファによるクラウド・スパコン間連携】

  • クラウド上のデータを使用するには、低帯域のWANが問題。
    • バーストバッファによるインタークラウド間のI/Oアクセラレーション
  • コストの問題から、クライアントにSSDを入れるのではなく、バーストバッファサーバとしてリモートファイルシステムとの間に入れている。

【塩基配列データベースを中心とした生命・医学系研究の解析基盤の構築】

  • 個人ゲノム情報のアーカイブを日米欧3極で運用開始。
  • DDBJはJST傘下のNBDCと共同でJGAを運用。
  • 可能なものはDockerに移していく。

【ユーザー駆動型・大域アプリ連成フレームワーク】

  • 連成計算アプリケーション
    • 複数のアプリで構成されるアプリが増えている。Ex:Pre-Post連携タイプなど
  • ネットワーク的に離れた他大学へノードをオフロードしても、処理性能が向上する場合がある。
    • 5コアを要するシミュレーションをオフロードした場合、 東工大4コア<東工大4コア+九州大1コア となった。
  • フレームワーク設計の方針
    • Well-knownサービスだけで構築

【Innovation at Global Universities by Amazon Web Services】

英語でのセッション。同時通訳はないので、スライド見ながらなんとか意味を理解するので手一杯。

以後は司会と懇親会準備のためメモなし。

3日目

【Dockerの概要、最新情報アップデート】

  • AmazonEC2ContainerService
  • GoogleContainerEngine
  • Hyper-V Container
    と出そろった。

【Dockerの分散に関する手法の提案と SDNへの対応】

  • CI環境をネットワーク設定まで同一な状態で提供しています。
  • なぜDockerに注目するのか。
    • 開発者の未来を変える
    • 洗練された機能だけが必要十分数存在している
    • コードが無駄に大きくない
  • 最初にaufsを採用したのがが秀逸。
    • 差分記録ができるので、同一イメージから複数のコンテナ起動ができる。
  • libnetworkはまだ発展途上。
    • 現状ではBridgeによるネットワークのコントロールとVXLANが少し実装されているだけ。
    • Windowsのドライバはファイルはあるがあきらかに動く代物ではない。
  • Wakame-vdc+OpenVNetでDockerを扱う。
    • Dockerのいいところは1台のマシンで動かすところ
    • オーケストレーションのツールは出てきたけれど…
    • 1つの大きなコンピュータに見せればいいじゃないか
      →仮想データセンタを作ろう!

Dockerのいいところだけではなく、変えたいところなどすばらしい講演。

【Dockerとインフラ運用自動化とIoT】

TIS松井さまからのお話。
Twitterのアイコンと顔がつながってよかった。

  • Dockerコンテナを使い捨てにするのであれば、オーケストレーションツールによる冪等性はなくてもかまわない。

【Mesosで作るDocker実行環境の共有】

次回のDockerハンズオンは10月前半に予定されているらしいので、ぜひいきたい。

【ハイパーコンバージドインフラによる仮想化環境とストレージの進化】

  • 無理矢理コンテナの話をねじこんだw
  • ストレージ拡張専用のノードもラインナップしました。

CloudStackユーザ会で直接聞いたときには、3ノードで400万ぐらいのグレードがあるとのことでした。

【DESTCloud のこれまでとこれから】

大学の同級生である柏崎くんのお話。

大阪大学主導でインタークラウドストレージの研究を行う。
ということで、協力ベンダーであるクラウディアン、スキャリティ様からの招待講演。

【インタークラウドストレージの検討】

  • PublicCloud間インタークラウドの課題
    • 基本的には条件が対等でないと契約が成立しない。
  • クラウドコネクターの事業が台頭してくる可能性は高い。
  • ストレージはCPUパワーをあまり使用しないので、
    • IoTのデータを受け取ったら、そこで保存してしまう。
    • 余剰のCPUパワーで計算してしまい、結果だけを転送する
      みたいな使い方も考えられる。

【Software Defined Storageを用いた広域分散構成の考察】

クラディアンと同様にS3互換APIを実装。このへんはオブジェクトストレージとしてどこも似たり寄ったり。
いずれにせよ、クラスタを組んだサーバの上段にLBをはさんでRESTのリクエストをノードに振り分ける。

  • イレイジャーコーディング/レプリケーションのポリシーが選択可能
  • コネクタサーバを挟んで、NFSやSMBのプロトコルも使用可能。
    • コネクタサーバにはキャッシュ機能を実装。
  • リコンストラクト時の不良発生を考えると、RAID6でようやく、ディスク1本の障害に耐えられると考える。
    • Yahooでは24時間、ディスクを差し替えつづける仕事もあったお…
  • レプリケーション:耐性重視。
  • イレイジャーコーディング:容量、I/O重視。(ファイル格納ノードが分割されることでシーケンシャルリードが上がる。)
  • イレイジャーコーディングのポイント
    • 利用効率が高い
    • スペアディスクが不要
    • スループットを高めやすい

クラウディアン様もスキャリティ様も 「ネットから拾ってきた絵ですから…」 と時事ネタw

| | コメント (0) | トラックバック (0)

2015/09/03

仮想化・クラウド担当者が知っておくべきコンテナ(Docker)解説 に行ってきた

コア技術だけでなく、運用向けの機能が充実してきた。というのが第一の感想でした。

【Dockerビジネス最新情報】

●「Bezosの法則」
  • クラウドサービス価格は3年の間に半分に下がる
    • →ハードウェアコストの減少分を値下げに充てている。
●クラウドサービスのTCOI構成要素
  • 35%:ファシリティ、電力コストなど
  • 30%:人件費
  • 35%:IT機器コスト
●IT業界の新たな動き
  • クラウド:普及に5年
  • Docker:普及に1年
    • アプリ層に近い技術ゆえ、直接的な効果が大きい
●Docker:1年の成長記録
  • 1300人のContributor
  • イメージダウンロード:累計5億
●今後採用する技術としての注目度
  • Fortune100で今後採用するIT技術として、Dockerがダントツの1位

「早く、イノベーティブ、ロックインからの回避」 がDockerの真髄。

●Docker1.8発表
  • DockerRegistry
    • S3,OpenStack(swift)でのイメージ管理に対応。

●米国連邦政府一般調達局(GSA)での導入
AWSがGSAが使用するIT基盤を共通化。
アプリはIT基盤をAPI経由で操作。
その後、アプリをすべてDockerに置き換えた。

●Dcokerに関する標準化
  • Open Container Initiative
    • Dockerの寄贈したDockerEngine(runC)の標準化を進める独立団体。
    • Linux Foundation傘下
  • CLOUD NATIVE COMPUTING FOUNDATION
    • GoogleがKubernetesのソースコードを寄贈。

これによって DockerEngineでのマネタイズは事実上不可能 になった。

●今後の動きへの予測
  • Dockerのエンタープライズでの実装事例は急増
  • VMとDockerの関係:両極端の議論が続く。
  • エコシステムの急激な成長と、Docker純正機能開発の協業/競争
    • オーケストレーション:DockerSwarm VS Kubernetes
    • ネットワーク/ストレージ管理:DockerNetwork:Google,VMWare,AWSなど
  • Dockerを軸としたビジネスモデルの登場
    • 単体では販売できる技術ではないことは市場が理解し始めている。
    • 開発者にとってのDockerは100%Free! → プロダクションサイトのDockerにビジネスが生まれる

【Docker最新情報アップデート】

@zembutsu さまのセッション

●DockerMachine
  • Docker動作環境の自動作成
  • コマンドラインで使うツール
  • Linux/Windows/MacOSXに対応
  • VirtualBoxだけでなく、多くのクラウドに対応
●DockerSwarm
  • Dockerクラスタ管理ツール
  • コマンドラインで操作

続きは http://docker.jp で!
これからドキュメント関連は↑にまとめていく予定

●DockerEngine1.8
  • ボリュームプラグインが安定版
  • ロギングドライバの提供開始
  • 細かな改善
    • docker daemon ,docker cp,docker ps --format,--config
●DockerContentTrust
  • TUF
    • コンテナ作成時に署名を可能に。
●見送りになった機能
  • NetworkPlugins
●DockerRegistry2.1
  • 新機能
    • Swiftのサポート
●まとめ
  • DockerHubがリニューアル
  • DockerToolbox提供開始
  • Docker1.8がリリース

普段のイベントと違ってスライドが固いなー、と思っていたら「ここから話変わるよ!」とネタスライド来たww

●Docker都市伝説
1.今すぐ始めなくてはいけない
2.全ての環境をコンテナにしなくてはいけない
3.仮想化システムは不要になる
4.構成管理ツールは不要になる
5.クラウド環境は不要になる
6.Dockerやコンテナが全て解決してくれる
7.Dockerは難しい
8.本番環境では使えない
9.セキュリティや信頼性に問題がある
10.Dokcerは冗長化できない
11.ネットワークが貧弱だ
12.よく落ちる
13.商用サポートを受けられない
14.DockerではなくCoreOSを使うべきだ
15.データの可用性が貧弱
16.Dockerがあればコスト削減できる
17.DockerはKubernetesがないと意味がない
18.Dockerやコンテナを使うとベンダーロックインされる
19.Dockerであれば業務効率化できる
20.そもそも、Dockerを使う意味が無い

だいたいはそもそものインフラ設計の誤りだったり、運用の問題だったり。
技術的な問題は時間が解決する。

【Dockerソリューション紹介】

  • RANCHERのデモでAWS上にリアルタイム展開。
    • NetworkAgentコンテナがIPSECでコンテナとの通信を提供する。
  • さまざまなクラウドのインスタンス作成/コンテナデプロイをGUIから操作するほか、RANCHER自身もRESTAPIとして動作する。
  • コンテナのWebコンソール機能もあり

| | コメント (0) | トラックバック (0)

2015/09/02

SoftLayer Bluemix Summit 2015 に行ってきた

【基調講演】

基調講演、といいつつ2~30分の細切れのタイムテーブル。

【OpenStackベースのホスティッド・プライベート・クラウド「Blue Box」とは】
で、
「OpenStack IS NOT Linux」 って文字がGNU's Not UNIX を彷彿とさせる。

【trackE:OpenStackベースのプライベートクラウドサービス「Blue Box」とは

@blueboxjesse
・パブリッククラウドの知見をプライベートクラウドに戻したい。
・OpenStackのユーザはハード、ネットワークを決める必要があった。
・Junoベースで構築、今年中にKiloに置き換えていく。
・Ursula/Giftwrapというツールを公開しています。
・92コア、384GB、3TB、/27のパブリックIPで$6500/月

同時通訳いらないぐらい、すげぇ聞きやすい英語。

【trackB:セキュリティから見る経営陣が納得するクラウドプロバイダーの選び方】

http://bit.ly/1Kqmg03
IDに対応するログが必要。サービス/サーバ単位ではない。

【trackC:Beaconを活用した行動解析の実態 ~必要なコストや、その効果・対策について~】

・Beacon検知で、会議室に入ったら資料をダウンロードとか面白そう。
Beacontrol アプリをAppStoreで公開中。
・設置したビーコンをフロアマップ上にプロットする機能がある。
・ログから行動をマッピングすることも可能。

【trackC:Bluemixを実案件(エンタープライズ)で使ってみてわかったこと】

残念ながらエンドユーザ名は明かせず。(日本の企業)

個人向け医療サービス情報webアプリのリプレース

現行:オンプレ/Oracle/Tomcat/JavaWebアプリ
たとえばまずはIaaSで…と提案しようと思ったら、 エンドユーザから Bluemixでと指定された。

●アプリケーション層
ランタイム:Python
Webフレームワーク:Django
コードリポジトリからPush

  • ログの課題
    • インスタンス内のログは再起動で消滅
      • ログをCloudantDBに格納
  • データストアはRDBだけではない
    • KVSやストレージサービスを活用
  • Bluemixならサービスで検証が容易
    • 開発/検証レベルでの活用性は高い

●データストア層

  • ディスク容量
  • サードパーティDBサービスは対象外
  • SQL Databaseサービス
    • Premiumプランで500GB。足りない。
      • 複数のインスタンスを起動して、ソフトウェア的にパーティショニング。
    • これを使うためにDB2を学んだ。
    • 今ならDB2 on Cloudもある。(開発当時はなかった)

●ネットワーク層

  • 管理者用APインターフェース
    *認証だけでなく、接続網で制限したい。
    • SecureGateway。ローカル側にDockerコンテナ
  • 機密データはローカルでストアしたい。
    • CloudIntegration。バックエンドをREST API化。フロントはクラウドを活用。

「データストア層をコンテナで、という議論はしない」

●開発プロセス

  • DevOps Services
  • コードリポジトリ→Push→デプロイ
  • デプロイ後の再起動で上がってこない
  • ログが少ない
  • 詳細を調べる方法がわかりづらい
  • 代替リポジトリ
    • Bitbucketを使用した。
    • SourceTreeを使用。(Git/Mercurial用GUI)
  • 全てのサービスは止まる/遅くなる前提
    • 代替サービスや代替策を用意する
  • それでも使う理由
    • デプロイの幅への期待
    • Agilityを高める環境が整っている

●Bluemixを使ってみてわかったこと

  • プロトタイプ開発向き
    • リージョンが米英のみ…
  • キャパシティ
    • スケーリング、ディスクサイズ拡張の選択肢がない。
  • セキュリティ
    • ソリューションは豊富。あとは信頼性。 
  • 課金
    • サブスクリプションはエンタープライズ向き
      • 予算が取りやすい。

●これから求めること

  • 商用サポート体制の明確化
    • 技術的問い合わせ                                                                                                                                              
    • パートナーとして商用観点
  • 柔軟なキャパシティプランニング
    • 柔軟な拡張性を。リミット管理も含め。
  • DevOps Servicesの機能充実
    • UI、タスク管理…
    • そうはいっても、Bluemixの真の価値はここにあると思います。

【trackC:ビッグデータ/クラウドにデータ連携自由自在】

AttunityReplicate のお話。

トランザクションログを監視して、レプリケート先にSQLを適用しているので…

  • 異種DB間の移行*統合
  • N:Nの複雑な構成でも容易に統合
  • フル同期から差分同期まで
  • DB側にエージェントレス
    が可能

実際にデモを行いました。
バックアップ用のレプリケーションではなく、データ移送が目的のツールです。
起動しておけば、クラウドtoクラウドでも10数秒遅れぐらいでのシンクが可能みたい。

ターゲット側にテーブルがない場合には作成してくれるなど、いろいろ便利そう。

| | コメント (0) | トラックバック (0)

2015/08/28

Spring in Summer ~ 夏なのにSpring

JoshLongを見られただけで価値がありました。 おすすめのセッションは「【R2-2.Spring Bootをはじめる時にやるべき10のこと】」です。

【R1-1.オープニングセッション】

オープニングトークであって、技術的にすごいことを話すわけではないので!との断りw

  • JavaEEが最近生意気だ!
  • JSUGは寺田が嫌い 、とかツイートするなよ!はダチョウメソッドじゃないよ!
  • アンケートを書いて回収BOXに入れるまでがイベントです。
  • JoshLongは今朝、成田に着きました。

年齢層はそんなに高くないなあ、という印象。

【R2-2.Spring Bootをはじめる時にやるべき10のこと】

資料、サンプルプロジェクトが公開されました。
ぜひ一読を。
http://www.slideshare.net/shintanimoto/spring-boot10
https://github.com/cero-t/spring-boot-kinoko-2015

「はまらない、ミスしない、ミスをリカバリできる。」がフレームワークに求めること。
その点で今のベストはSpringBoot。

#1 SpringBootを知る。
複雑化したSpringプロジェクト群を使った開発を簡単に始められる仕組み。

  • フルスタックプラットフォーム
    • いろいろなFWを組み合わせるとハマりがある。

#2 はじめてのSpringBoot
新しいプロダクトの利用時あるある

  • ドキュメントがない、英語しかない。
  • 少しずつググりながらなんとかしのぐ

#3 SpringInitializr
プロジェクト立ち上げ時あるある

  • pom.xmlを書くのは面倒で、Exampleからソースのみ削除して流用
  • 変なJarが混じってる
  • バージョンが違う
    • はまりが発生する。

https://start.spring.io/

  • 必要な情報と利用するモジュールを選ぶ。
    • Actuatorおすすめ。
      ダウンロードしたPOMを使って、mvn spring-boot:run

#4 pom.xmlの設計
pom.xmlあるある

  • 依存Jarのバージョンを複数のpom.xmlに重複して書いている
  • 親子モジュールとか難しいから単一で
    • WebAPIとバッチが同じJarに…

pom.xml のグッドプラクティス

  • デプロイ単位、ライフサイクル単位で分割
  • 共通部分を切り出す。
  • 依存Jarのバージョンは親のpom.xmlに書く
  • Spring IO platformを使う。
    • 大げさな名前だが、ただのpom.xml
    • Spring関連だけでなく、著名なプロダクトも含むバージョンを規定したpom.xml

「Mavenは人類には早すぎた」

#5 Controllerの共通設定
java.uril.DateやCaendarはハマりやすい

  • 余計な時分秒があるせいで判定を誤る
  • Calendarで時分秒に0を入れてもミリ秒が残る

JSR310をSpringBootで使いたい。
ControllerでLocalDateを使う

  • なぜかLocalDateはJsonで返せない
  • Controllerで利用するJacksonをカスタマイズする。

レーザーポインタなくて、傘を指し棒にw

${color:red}「入力は柔軟に、出力は厳格に」%

#6 トランザクション境界の設定
トランザクションあるある

  • Controllerをトランザクション境界にする
    • 処理の途中で一度コミットしたいけどできない
    • 途中でコミットできるような仕組みを無理に作ったら全体的な整合性が崩れた
  • 性能改善のためのリードレプリカを作りたいが、そもそもアクセスを振り分けられない

Service層をトランザクション境界にする。

  • Controllerの次の層をトランザクション境界にする。
    • 処理の単位が明確になる。
    • Service層からReturnすればコミット、例外で戻ればロールバック

原則、ReadOnlyトランザクションを使う

  • Service層のクラスすべてに@Transactional(readOnly=true)をつける
  • 更新が発生するときだけ、@Transactional(readOnly=false)にする
    • リードレプリカへの振り分けが容易に。

#7 O/Rマッパーの選択
O/Rマッパーあるある

  • とりあえずHibernate
    • 思ったのと違うSQLが発行された
    • 1リクエストでSQLが1万回発行された

「Hibernateは人類には早すぎた」

  • じゃあMyBatis
    • SpringBootで標準対応していない
    • SQLを書いたXMLをフォーマットしたらインデントが全部消えた
  • じゃあJdbcTemplate
    • なんかAPIが古くさい
    • publicフィールドが使えない
    • JSR310に対応していない
  • Bootiful SQL Template
    • JdbcTemplate/NamedParameterJdbcTemplateの独自ラッパーとして作った。
    • SQLファイルをかける。FreeMaker形式も可
    • モダンなAPI
    • publicフィールドが使える
    • JSR310に対応(ZonedDateTimeも)

#8 例外処理の共通化
例外処理あるある

  • 個別の開発者任せ。
    • もちろん死ぬ
  • フレームワークが返す例外とアプリケーションが返す例外でJSONの形式が違う。
    • クライアント側で判別が必要で死ぬ。

例外処理は共通化する

  • ApplicationException extends RuntimeExceptionを作って、必ずこれを使う。
  • エラーコードはenumに定義しておき、コンストラクタの引数に必ず渡す。

「すべての例外を共通化してハンドリングせよ」

#9 AOPによるロギング
AOPとは

  • アプリケーション横断的に行う処理
    • トランザクションのコミット、ロールバックもAOPで実現されている

#10 テスト設計
テストあるある

  • とりあえず、手動でテストしようぜ!
    • 回帰試験で死ぬ
  • ロジックがあるControllerからテストすればOK
    • バリデーションの設定ミスで死ぬ
  • 通常使うComponentとモックのComponentは@Profileで切り替える
    • 管理で死ぬ

テストのグッドプラクティス

  • Controller以降をJUnitでテストする
    • カバレッジは最低60%、できれば80%を目指す。
  • 外部サービス呼び出しはモック化する。

テストのTips

  • @Componentのモックは@Profileよりも@Primaryをつけた方がよい。

【R2-3.大規模* 長期保守を見据えたエンタープライズシステム開発へのSpring Frameworkの適用】

●TERASOLUNA Frameworkとは
Struts1でもきちんとパッチを作ってるが、業界の動向を考慮して新たなTERASOLUNA FWの提供を開始。
http://terasoluna.org/

なぜSpring?

  • シェアNo1
  • JavaEEは仕様策定までに時間がかかりすぎる

ソフトウェアスタック

  • SecurityLayer:SpringSecurity
  • ApplicationLayer:SpringMVC,JSP,BeanValidation
  • DomainLayeer:Spring(TX)
  • InfrastructureLayer:MyBatis3,SpringDataJPA

●SpringFrameworkを利用したときの課題
☆Springのバージョン組み合わせ選定

  • 各Springサブプロジェクトのどのバージョンを使用すべきか?
  • サードパーティライブラリはどのバージョンを使用すべきか?
    • Spring IO Plaformで解決!

TERASOLNA FWが依存、推奨する66ライブラリの管理をIO Platformに委譲。

☆Spring等の膨大な設定

  • 必要な設定が漏れていたり、初期値のまま使われてしまう。

☆乱雑なプロジェクト構成
よくある課題

  • 複数のプロジェクトで構造の一貫性がとれていない
  • コードや設定が特定の環境に依存し、テストのしやすさが考慮されていない

「TERASOLUNAでは以下のようなブランクプロジェクトを提供します。」

  • 例や分割したマルチプロジェクト構成
  • 環境依存を集約
  • 各種設定、ライブラリ依存関係が設定済み

mvnコマンドでブランクプロジェクトを作成できます。

☆不完全な例外ハンドリング* ロギング
以下の4パターンを提供

  • try-catch
  • @ExceptionHandler
  • HandlerExceptionReolver
  • error-page

ハンドリングに必要なxml設定はブランクプロジェクトで設定済み。

☆信頼性の低いコードの模倣
FWとしてのガイドラインを提供します。

☆フレームワークの長期利用
すべてのサンプルコードのテストをseleniumで書いています。
リリース前にすべてのAPコンテナ、JDKの組み合わせでオールグリーンを確認。

【R1-4.超高速開発ツールWagbyの技術基盤】

ランチセッションなのでまったりと。

excelでJSONパーサ書いた人がいるので、それを使ったデモ。
Wagbyで作成したアプリをRESTAPI化して、そこから顧客情報を取得→excelのセル埋め。

【R1-5.キーノート The Macro of Microservices】

JoshLongの登壇。
・プロジェクタがうまく動かず、しばらく手間取ったあと「コンピュータはバカだな」とw
・38時間かけて日本にやってきたんだよ!
・プロダクションはディズニーより楽しいよ!
・やったーWaterFallだ!なんて喜ぶヤツはいないだろ?

JoshLong、すげぇおもしろい。

https://speakerdeck.com/joshlong/the-macro-of-microservices

【R1-6.Spring DIと大規模プロジェクト、春は来るのか本当に?】

HUEプロジェクトの中でのSpringの話。
まあ、PJの苦労話は鉄板ですわね。

  • 社長の「いまどきRDBMSなんてないよね」の一言でCassandraに。

@Autowired使ってますか?

  • Springといえば!
  • ComponentScanの恩恵は受けたい。

●時間の経過とともに…

  • AP起動時間が遅くなっていく
  • プロジェクト間の依存関係が
  • 依存性の注入って言うけど
    • 結局、何が読み込まれているの?人間の思念ですか?

●結論
Modularityの担保

  • 実装とIFの分離
  • フレームワークの設定は@Importで管理
  • 2重ロードの防止
  • 速度の考慮
    • ComponentScanをしないという選択肢

特に問題なく使えてる…はずだったが

●表面的に噴出した問題
依存関係が謎。解決できない

  • ComponentScanの推移的依存解決のせい。
  • 起動時間が遅い
    • basePackage対象以下のフルスキャンが走るので遅い。
    • Bean生成時の問題
      • コンストラクタでDB読み込み…
  • プラグイン的に扱うものは?

●人が増える=Jarが増える
どんどん遅くなる

  • Eclipseだともっと遅い

●ソリューション
フレームワーク開発者

  • 速度を重視。Scanをしない。
  • @Componentにあたるものは自前で管理。

業務開発者

  • 効率を重視。Scanする。

●なぜ?Scanしない?
Scanしない。

  • アノテーションベースDIからJavaベースDIへ。
  • @Configurationを有効活用
  • @Beanも有効活用
  • applicationContext.xmlは使わない。
    メリット
  • 依存の整理が楽
  • テストも一元化
  • Grep天国からの決別

●こうすると実は問題が…
N回読み込まれる問題

  • 空振りすればよいが、名前が被ると重複登録
    • @GuardedConfigurationを内製しました。

●おまけ:傾聴
開発者の愚痴に敏感に。

  • 作りにくい
  • 時間かかる
  • 何でこれ?
  • なんか怒ってる、諦めてる。

バグ管理とかに現れない愚痴が大事。

【R1-7.The Bootiful Application】

ここもJoshLong。
IntelliJユーザは手をあげて?→多数
Eclipseユーザは?→多数
NetBeansユーザは?→いない

「どこにいってもNetBeansユーザがいるんですが、今日は潜り込めなかったようだなhahaha」
「Springチームはみんな禿げてる。みなさんにこのようなサービスを提供するためにがんばっているからだ。」

ライブコーディングに合わせてのお話。
一流の技術者は一流の芸人でもありました。

https://speakerdeck.com/joshlong/the-bootiful-application

【R1-8. 【前半】 Spring Framework/Boot/Data徹底活用~Sprnig Data Redis編~【後半】 Spring適用のアンチパターンとベストプラクティス(仮)】

朝からずっと聞いて疲れたので流してた。

http://www.slideshare.net/yoshidanaohiro52/spring-framework-boot-data-spring-data-redis
http://www.slideshare.net/Yoichi-KIKUCHI/jsug2015-summer-spring

| | コメント (0) | トラックバック (0)

«夏サミに行ってきた