＜オープニング 各種告知＞
6/1～3 AWS Summit Tokyo
＜東急ハンズのEC2の使いかた＞
緑本：Amazon Web Services 実践入門
AWSエキスパート養成本 今月発売予定
使い始めて３年経過
ハンズメッセ
→高負荷
→これをEC2で構成。
→Amazon Linux
POSサーバ
東芝テック制
Windows Server2008
→テックには、IAMユーザで運用保守。
メルマガ配信システム
RedHat Enterprize Linux 6
Oracle 11g
AWSブログ→無料、RSS登録が便利
公式(日本語)
AWS Black Belt Tech Webinar(無料)
→これをすべて理解すれば脱初心者
→EC2,EBS,VPC,S3
re:Invent
→セッションがyoutubeで公開されている。
＜Simple Front 53＞Sansan
Ｓ３
99.99999999999(イレブンナイン)
ログの保存
fluentdのS3 pluginで定期的に
応用例
→静的ウェブサイトホスティング+JavaScript+Congnito
CloudFront
便利なCDN
動的なコンテンツでも使うと良い
独自のDDoS監視システム
ウェブサイトのSSL/TLS対応
地域に応じた～～～
CDN
→キャッシュによるオリジンの負荷低減
コネクションの最適化
ウェブサイトのSSL/TLS対応
・CloudFront+S3で最強静的ウェブサイト
・HTTP/2未対応
→コーポレイトサイトとか。
無料でかつ更新不要。後ろにS3の構成。
低コストウェブサイト運用
同一URLでも国別のコンテンツを表示
(IPで判別)
AWS WAFとの統合
セキュリティ対策
WAF+CloudFront
Route 53(fifty three)
安くて手間いらずのDNSサービス
SLAで可用性１００％
DNSキャッシュサーバではない
AWS CLIでの管理は大変
→簡単操作ならマネージメントコンソール
→自動化はSDK利用がおすすめ
(JSON)
加重ラウンドロビン
＜ぎょりと学ぶAWS Billing+契約の学び方＞
オンプレミスで考えた時の構成
AWS事例みて試算する。
説明には企業名は書かない
AWS TCO で検索！
→比較
＜LT＞
インスタンスタイプ気をつけて！
slack情報を流した
----
緑本でインフラお勉強
→わかりやすい
----
構成図を書いて覚えよう！
→サービスの特性が掴める
AWS シンプルアイコン
Cacoo オンライン作成(無料で使える)
----
ビリングの章、おすすめ
NTTドコモではAWS使ってる
コスト問い合わせ多い。
----
＜AWS初心者がウェブサービス作ってみた結果ｗｗｗ〜主に失敗事例〜＞
デカケル.jp
アプリのデプロイ
→毎日変更
Elastic Beanstalkの良い点
→Git経由なのでバージョン管理きちんとできる
ストレージ
Wordpress
＜クロージング & 次回予告＞
2016年2月18日木曜日
2016年2月15日月曜日
JJUGナイトセミナー 「Java EE 7徹底入門」の著者が解説！ - Java EE 7特集 に行ってきた！
＜Java EE 7徹底入門 概要説明 (猪瀬さん)＞
書籍『Java EE 7徹底入門』著者
→サンプルアプリ作成できるので、今後活用してもよい。
.ear = .jar + .war
Java EE 7
→2013年
次世代フレームワーク
→検討する上で情報量が大切。
＜プレゼンテーション層の開発 JSF (加藤田さん)＞
(当時)Servletでは、入力チェックがないためOSS(struts等)を利用していた。
JSF構成要素
→フェースレット(画面)とマネージドビーン(処理)
XHTMLベースのテンプレートエンジン
JSF
→サニタイジングがデフォルト等。JSP進化版。
@Named フェースレットと連携しますよ～
@RequestScoped スコープの定義
本書で触れられなかった話
・JSFのより詳細な機能
→カスタムコンポーネント
イベントハンドリング
ビーンバリエーション
EL
・JavaEE 8(JSF2.3)
→WebSocket対応
マルチフィールドバリデーション
・MVC1.0
→アクション指向フレームワーク
JavaEE8で導入
JAX-RSを拡張(アノテーション同じ)
・JSF関連ライブラリ
プレゼンテーション層の選択肢
１．JSF
２．JAX-RS+クライアントサイドフレームワーク
３．MVC1.0＋Web Components?
どれを選んでいてもコンポーネント指向に収束。
→人間がイメージしやすいのかも。。
PrimeFaces
→Ajaxベース。100を超えるコンポーネント
OmniFaces
→JSF開発をサポートするユーティリティライブラリ
＜ビジネスロジック層の開発 CDI,EJB (羽生田さん)＞
CDIとEJBの組み合わせがよい。
CDI
→インジェクション、型解決、定義方法
→イベント処理
EJB
→解説。きちんと設計すれば
CDIコンテナの取り扱い
@ConversionXXXXX
CDIにおけるトランザクションの取り扱い
DI
→「層」をくっつける接着剤の役割
スコープ定義
@RequestScoped
@ViewScoped
@SessionScoped
@ApplicationScoped
@ConversationScoped → 開発者が明示的に決める事が可能
スコープ外になるとGC対象になるので。
CDI
→スコープ定義がわかれば使えるため、簡単。
層について
JSF⇔CDI⇔Entity
※ただし、CDIは実際は全ての層に入るはず
CDIコンテナ
・Weld
→バージョンは必ず認識(APサーバとの関連)すること。
環境によって動かないみたいなことがある。
Glassfish/Weld、Oracle Weblogic/Weld
・CDIコンテナへのアクセス用
→取得：CDI.current();
CDI.select(MyBean.class).get();とか
・CDI.current().toString();
→返却：Weld
・CDIProvider
・BeanManager
→面白い機能。
@Inject
BeanManager manager;
業務アプリで使いすぎると危険
過度の使いすぎ→FW化→障害調査が大変
・大規模開発だと勝手インジェクションとか。。。
@ConversationScoped
・自分でスコープ長を定義
・begin()→end()
トランザクション
・javax.transactionパッケージ
・@Transactional
→トランザクション境界の設定
→クラスとメソッドどちらでも
・@TransactionScoped
CDI＋EJB
→ルール決めが大切
多量のインジェクション数は危険
→課題。フレームワークで制御しようとすると本末転倒になりそう。
だから設計大事。
＜バッチアプリケーションの開発 jBatch (猪瀬さん)＞
JavaEE7から登場
Spring Batchから多く継承
JSR-352で規定
１．プロセスとして実行
○ シンプル。直感的。
△ JVM起動時間のオーバーヘッド。CPU浪費。
△ APサーバで動く他の部品との共有が難しい
２．自作スレッドとして実行
○ スレッドはプロセスに比べて軽く起動
△ スレッド管理するmainプログラムを自作必要
△ APサーバで動く他の部品との共有が難しい
３．サーブレットとして実行
○ スレッドはプロセスに比べて軽く起動
○ スレッド管理プログラムの自作不要
○ APサーバ部品との共有OK
△ 実行状況の把握、スレッド停止が難しい
△ HTTPリクエストタイムアウトの問題
４．jBatchを利用
○ スレッドはプロセスに比べて軽く起動
○ スレッド管理プログラムの自作不要
○ APサーバ部品との共有OK
○ 実行状況の確認OK
ジョブとステップ
→ジョブ(xml)はステップの入れ物
JCLっぽい。
ジョブオペレータ
ステップ
→『チャンク型』『バッチレット型』
→チャンク型：一括処理
I/O減らす仕組み(10回に1回書き込み)
補助機能
・リスナ
・コンテキスト
→JobContextとStepContext
・メトリック
→Stepに関する統計情報
書籍『Java EE 7徹底入門』著者
→サンプルアプリ作成できるので、今後活用してもよい。
.ear = .jar + .war
Java EE 7
→2013年
次世代フレームワーク
→検討する上で情報量が大切。
＜プレゼンテーション層の開発 JSF (加藤田さん)＞
(当時)Servletでは、入力チェックがないためOSS(struts等)を利用していた。
JSF構成要素
→フェースレット(画面)とマネージドビーン(処理)
XHTMLベースのテンプレートエンジン
JSF
→サニタイジングがデフォルト等。JSP進化版。
@Named フェースレットと連携しますよ～
@RequestScoped スコープの定義
本書で触れられなかった話
・JSFのより詳細な機能
→カスタムコンポーネント
イベントハンドリング
ビーンバリエーション
EL
・JavaEE 8(JSF2.3)
→WebSocket対応
マルチフィールドバリデーション
・MVC1.0
→アクション指向フレームワーク
JavaEE8で導入
JAX-RSを拡張(アノテーション同じ)
・JSF関連ライブラリ
プレゼンテーション層の選択肢
１．JSF
２．JAX-RS+クライアントサイドフレームワーク
３．MVC1.0＋Web Components?
どれを選んでいてもコンポーネント指向に収束。
→人間がイメージしやすいのかも。。
PrimeFaces
→Ajaxベース。100を超えるコンポーネント
OmniFaces
→JSF開発をサポートするユーティリティライブラリ
＜ビジネスロジック層の開発 CDI,EJB (羽生田さん)＞
CDIとEJBの組み合わせがよい。
CDI
→インジェクション、型解決、定義方法
→イベント処理
EJB
→解説。きちんと設計すれば
CDIコンテナの取り扱い
@ConversionXXXXX
CDIにおけるトランザクションの取り扱い
DI
→「層」をくっつける接着剤の役割
スコープ定義
@RequestScoped
@ViewScoped
@SessionScoped
@ApplicationScoped
@ConversationScoped → 開発者が明示的に決める事が可能
スコープ外になるとGC対象になるので。
CDI
→スコープ定義がわかれば使えるため、簡単。
層について
JSF⇔CDI⇔Entity
※ただし、CDIは実際は全ての層に入るはず
CDIコンテナ
・Weld
→バージョンは必ず認識(APサーバとの関連)すること。
環境によって動かないみたいなことがある。
Glassfish/Weld、Oracle Weblogic/Weld
・CDIコンテナへのアクセス用
→取得：CDI.current();
CDI.select(MyBean.class).get();とか
・CDI.current().toString();
→返却：Weld
・CDIProvider
・BeanManager
→面白い機能。
@Inject
BeanManager manager;
業務アプリで使いすぎると危険
過度の使いすぎ→FW化→障害調査が大変
・大規模開発だと勝手インジェクションとか。。。
@ConversationScoped
・自分でスコープ長を定義
・begin()→end()
トランザクション
・javax.transactionパッケージ
・@Transactional
→トランザクション境界の設定
→クラスとメソッドどちらでも
・@TransactionScoped
CDI＋EJB
→ルール決めが大切
多量のインジェクション数は危険
→課題。フレームワークで制御しようとすると本末転倒になりそう。
だから設計大事。
＜バッチアプリケーションの開発 jBatch (猪瀬さん)＞
JavaEE7から登場
Spring Batchから多く継承
JSR-352で規定
１．プロセスとして実行
○ シンプル。直感的。
△ JVM起動時間のオーバーヘッド。CPU浪費。
△ APサーバで動く他の部品との共有が難しい
２．自作スレッドとして実行
○ スレッドはプロセスに比べて軽く起動
△ スレッド管理するmainプログラムを自作必要
△ APサーバで動く他の部品との共有が難しい
３．サーブレットとして実行
○ スレッドはプロセスに比べて軽く起動
○ スレッド管理プログラムの自作不要
○ APサーバ部品との共有OK
△ 実行状況の把握、スレッド停止が難しい
△ HTTPリクエストタイムアウトの問題
４．jBatchを利用
○ スレッドはプロセスに比べて軽く起動
○ スレッド管理プログラムの自作不要
○ APサーバ部品との共有OK
○ 実行状況の確認OK
ジョブとステップ
→ジョブ(xml)はステップの入れ物
JCLっぽい。
ジョブオペレータ
ステップ
→『チャンク型』『バッチレット型』
→チャンク型：一括処理
I/O減らす仕組み(10回に1回書き込み)
補助機能
・リスナ
・コンテキスト
→JobContextとStepContext
・メトリック
→Stepに関する統計情報
2016年2月10日水曜日
第31回PaaS勉強会に行ってきました
１．microPCF を使ってみよう(hiroakiukaji さん)
Cloud Foundryの完全自力運用はつらい、らしい。
BOSH 分散システム構成管理ツール
→これもつらい、らしい。便利だが学習コスト高い。
Cloud Foundry All-in-Oneの一つ
→microPCF
microPCF
→Cloud Foundry構築ツール
3stepでお試しできた。
以下を比較。
bosh-lite
cf_nise_installer
microPCF
２．runC について(yo_ さん)
Dockerの周辺事情
→centOSからいじめられた。。
→OCI発足(コンテナの標準仕様を議論・策定する団体)
DockerとrunCの技術的関係
runC 必要なこと
→Go言語がコンパイルできる。
３．OneOps の仕組みと使い方(jacopen さん)
http://www.publickey1.jp/
Walmartと言えば
→50兆円くらいの売上高
OneOps
→OSS。Walmart Labsが開発
→JavaとRubyで書かれている。Chefも使っている。
→Cloud Formationに近い。
必要な構成を生成してくれる。
→本当に成熟してくるとインフラエンジニアの役割は確実に変化していく。
複数のCloudの比率を設定して、生成ができる。
→AWS:Azure 3:1みたいに。
openShift等とは違う。
４．今さら Cloud Foundry 百日行振り返り(nota-ja さん)
http://blog.cloudfoundry.gr.jp/2015/06/cf100apps-000.html
Buildpacks
unicale カレンダーアプリ
５．cf-containers-broker を使ってローカル環境もサービスの恩恵をうける(morika-t さん)
NTTソフト Cloud Foudry
http://www.slideshare.net/morika-t/cfcontainersbroker-58094120
６．Lattice でコンテナ間通信 その2(shinohara_kenta さん)
Dockerではコンテナ間通信の仕組みたくさん
Cloud Foundryの完全自力運用はつらい、らしい。
BOSH 分散システム構成管理ツール
→これもつらい、らしい。便利だが学習コスト高い。
Cloud Foundry All-in-Oneの一つ
→microPCF
microPCF
→Cloud Foundry構築ツール
3stepでお試しできた。
以下を比較。
bosh-lite
cf_nise_installer
microPCF
２．runC について(yo_ さん)
Dockerの周辺事情
→centOSからいじめられた。。
→OCI発足(コンテナの標準仕様を議論・策定する団体)
DockerとrunCの技術的関係
runC 必要なこと
→Go言語がコンパイルできる。
３．OneOps の仕組みと使い方(jacopen さん)
http://www.publickey1.jp/
Walmartと言えば
→50兆円くらいの売上高
OneOps
→OSS。Walmart Labsが開発
→JavaとRubyで書かれている。Chefも使っている。
→Cloud Formationに近い。
必要な構成を生成してくれる。
→本当に成熟してくるとインフラエンジニアの役割は確実に変化していく。
複数のCloudの比率を設定して、生成ができる。
→AWS:Azure 3:1みたいに。
openShift等とは違う。
４．今さら Cloud Foundry 百日行振り返り(nota-ja さん)
http://blog.cloudfoundry.gr.jp/2015/06/cf100apps-000.html
Buildpacks
unicale カレンダーアプリ
５．cf-containers-broker を使ってローカル環境もサービスの恩恵をうける(morika-t さん)
NTTソフト Cloud Foudry
http://www.slideshare.net/morika-t/cfcontainersbroker-58094120
６．Lattice でコンテナ間通信 その2(shinohara_kenta さん)
Dockerではコンテナ間通信の仕組みたくさん
登録:
投稿 (Atom)