Seeing is believing

いちエンジニアの日々の興味のあるところ、イベント参加記録、学びの共有を取止めなく※このblogは個人の見解であり所属する組織の見解ではありません

JAWS Days2017に参加してきました。かなり勉強になりました。

AWS Days2017 3.11 @TOC五反田メッセ のメモ。

初めてのJAWS Days参加でどんな雰囲気なのか心配でしたが、

エンジニアの集まり、お祭りな感じでとても楽しく、沢山の得たことあったなぁ。と

充実した1日でした。

 

参加したセッションを中心に。

 

- サーバレスアーキテクチャ

資料

 

www.slideshare.netLambdaの場合、処理がぬけた部分を考慮する必要がある
特有の課題を回避する必要あり。タイムアウト、リトライ実装必須。

EC2でも良いなら、そちらが安定。

DBの必要性を確認。S3で問題ない場合も多数。
LambdaとEC2の違い。
RestfulなAPIができれば良い話ではない。

  • Lambda:1対1


Lambdaには、運用でカバーで甘えられない現実がある
サーバレス開発は運用メンバーがフォローしてくれない。全て開発者に不具合が返ってくる。
実行されないことも含めてモニタリングが必要。
 →これまでインフラ部隊がやってくれた
非機能要件を開発者が実装する必要がある。守るところを守れるようにする。

運用時に不具合が発覚した場合もリカバリー処理を考慮した設計が必要で
開発時のコストが上がる現実。(運用費用は下がる)
TCOでの比較で決めていくべき。

MBS動画イズム444の事例→3ヶ月でリリース
cloud front + S3で大量アクセス不可への耐性の確保した。
dbを使わず、S3だけ。
月々のインフラコストを削減するためにサーバレスアーキテクチャを採用
フロントでできる処理はなるだけフロントで対応。(非会員はこれで十分)
→Lambdaをできるだけ使わない設計としている
処理時間が長いものはworkerを使って分散。
kintone(CMSとしても利用。セキュリティアクセス管理はお任せ)のサービスを利用しているが、APIの利用制限があるのでなるべくまとめてAPIをコールする。
世界三箇所から相互にモニタリングする仕組みを作っている。
監視間隔は5分。
モニタリングしているシステム同士も監視し合っている(3すくみ状態)。
lambdaベースで監視システムも作っているのでインフラコストを下げている(無料枠に十分収まる)
不正アクセスによるLambdaの実行回数制限を狙った攻撃への防御対応が必要だった。(APIのURLを知ると、攻撃可能)
1分間隔で不正を検知し不正IPをブロック。


- Fintech 最前線 渥美さん


立ち見も出るほどの盛況ぶり。200人ぐらい。
メガバンクも利用。日経からの3つの記事がでた。自身も勉強会で訪問した。
新規案件のうち50%、既存システムは更改時にクラウド化。→クラウドファースト
グループ共通の共通基盤とする。
3システムが稼働中。
10件弱開発中。20件検討中。
2017年中にAWSの資格習得者を30人育成
FIN TECH
リーマンショック、エンジニアが流出
格差拡大、Unbank、金融機関への不信
新テクノロジーとスタートアップが始まり
会議ではこの2−3年で投資が急激に拡大
海外では、既に金融機関を脅かしている
金融庁の危機感。→ワーキンググループを組成。
銀行のビジネスモデル→ソフトウェア産業化、APIエコシステム化
FISC安全対策基準第8版で(2015/08)リリース
金融機関におけるクラウド利用が示された
「現地サーバ視察は不要」
立入監査が実行的でない場合などは、第三者関西による代替も可能。
金融庁によるFINTECHアクションプランが(仮想通貨をいつまでに検討する、など)公開されている。
キーワードがイノベーション。ブロックチェーンなどの記載もあり。
FINTECHは登録制とする。ただし、スピード感は大切にする。(きぞんよりもゆるい、安全対策基準を設ける)
OpenAPIによる変化
今:電子決済等代行業者にID/PWを提供して、スクレイピングで銀行へアクセス(米国では主要だが、欧米では慎重)
OpenAPI:Fintech企業による代行。OAuth2.0でトークンでやりとりする。
一般社団法人FinTech協会の動きが活発になってきている


- コンテナに挫折したあなたへ
JAWSUGコンテナ支部 原さん
資料

speakerdeck.comコンテナとVMの違い
VMは配る際もOSも必要なので、稼働から、OS設定などが必要。電源を入れる的な作業が必要。
コンテナはDockerのデーモンプロセスが間に入るだけ。OSはない。
AWSの場合は、ゲストOSとしてEC2を使って、そのOS上でDockerを動かして、
その上でコンテナが動く。
Dockerコンテナ上のプロセス出会ってもホストOSの上でもpsで見える。
ただし、Linuxコンテナの技術を使って、違いに干渉しないように見えるので
プロセスIDの表示が異なる。コンテナの中からは自分のコンテナの中しか見えない
SI企業への発注の場合、ソースコードと、Dockerファイルをあわせて納品させると
UATで動かない、といったことがない。
コンテナはモダンなアプリケーション開発のベストプラクティスに沿ってない。
12-Factor app:Herokuが元になっている良いアプリケーションのベストプラクティス(2012-2012から変わっていない。その当時はDockerはない)
awsのwebinerでAWSにおける12-FactorAppについて50分説明しているものがあり。
コンテナに適した

  • チーム体制とデリバリー
  • アプリケーション(これが一番大事。ログを適切に吐くとか。IPが固定されていることが前提の作りとか。ディレクトリにここにファイルがあること前提とかにしない)
  • 運用(管理タスクもコンテナに)
  • インフラ構築

を明確にし、何がかけているのかをはっきりさせる
コンテナ登場以前のデリバリーソースコードコミットをトリガーにCIサーバがフックしてシェルべったりで実行環境にデプロイ

一方、コンテナ時代はCIサーバが直接デプロイではなく、Docker Registryに上げるところまで。
クラウド常にコンテナ管理ツール+事項環境となりうる。


実行定義に、イメージ、CPUメモリ、アプリ設定値、マウントするディレクトリ、公開するポート、コンテナ内で走らせるコマンドなど
を定義することで、どこの環境でも動くようにする。
世の中のコンテナ管理ツールは、非同期的な動きになっている。
クラスタ:複数のソースを1つのインスタンスとしてみなす。
リソースの有効活用。どこでも動かせる、いつでも復旧できる、に繋がる。
クラスタ時代はCPU利用率で見るのではなく、CPU予約率でメトリクスをみてスケールを判断する。
予約率が厳しくなってきたら、クラスタに追加した形でリソース追加
オススメは1プロジェクトで1クラスタ。例外があるとすると、バッチ処理だけ別にする。(時間が読みやすいので)

- AWSでアプリ開発するなら 知っておくべこと

 

www.slideshare.net参加したかったけど、時間に間に合わず。資料を後ほど読み込んで理解したい。

- [DeepDive] AWS SECURITY DEATH \m/ ~セキュ鮫様からのお告げ~ by Security-JAWS
資料

JAWS DAYS 2017 Security-JAWS発表資料 // Speaker Deck


セキュリティ関連でも何か検知して何かを処理する場合は
Lambdaを使うというのが勉強になった。オンプレでのシェルやバッチ相当の汎用性がある。

JJUG CCC2016Fall(Winter?)に参加してきました。

JJUG CCC2016Fall(Winter?)に参加してきました。ここ最近は参加していますが、刺激的で、考えさせられるセッションが多いです。

1000人ぐらい参加したのではないだろうか、というぐらい人が多かった。。

コミュニティイベントとしては国内最大級かと思われます。

www.java-users.jp

参加したセッションの紹介と参加中に取ったメモを残しておきます。

  • Be a great engneer! フォローするトレンドとスルーするトレンドの見抜き方

speakerdeck.com

Pay it forwardのOSS精神は大切。
JSFXDoclet,Guice,Silverlightなど、、流行らなかった技術、プロダクト、トレンドなどが沢山あったが、どうすれば良かったか、という自己振り返りから作成したセッション。

審美眼を磨くために必要なこと → 自分で考えること
技術を見たときに本質を何か考える→技術をメタで考える
体:操作
物:パターンなど
知:深い知識
心:メンタル
理:本質を理解

本質は自分で動かし、自分の頭で考え、本質を見抜いた物が真理
人から聞いた「理」ばかりを語るのは空虚。
守:師の教えを守る
破:自分で考える段階
離:独自のセオリーを想像する段階
本ぞを忘れるな:教わった基本を忘れるな
〇〇宣言とか、〇〇Manifestには真理が詰まっていることが多い

技術の仕入れ元は?→技術カンファレンス。最近ではSpringOne.
Thoughtworks,Technical Radar:その技術がどの段階にいるのかが分かる
ガートナー社のイベント:トレンドを踏まえて次の1年から先の数年を予見した発表を行う
 →機械学習、IoT,AR,VR,ブロックチェーン、メッシュアプリ
  →それらを支えるのが、マイクロサービスアーキテクチャ、サーバレスアーキテクチャ、分散ストリーミング
マイクロサービスは本質的には、アジリティとスケーラビリティを実現するための技術
 そのニーズはあるか?導入するためのコストは払えるか?組織には導入の土壌があるか?

  • SIerもはじめる、わたしたちのDevOps

www.slideshare.net

お客様がDevOpsしたい?ツール入れたい× リードタイムを短くしたい○
ユーザーの行動を可視化→Kibana。改善提案。
仮説を立てることが重要。仮説に合わせてログの収集の仕組みを変える必要がある。
Dockerが実現する世界。確認済みのインフラ、アプリがそのまま使える。


Dockerを導入するためには、変化に強いシステムに耐える組織が必要。
→適材適所、組織改革が必要。

 

  • Spring Cloud Stream 

www.slideshare.net

クラウドの時代になり、Httpではなく、MQなどイベントドリブンに回帰してきているんだなあと思ったのが印象的でした。リアクティブの流れも当然なのですね。。

Spring Cloud Stream とはイベントドリブンなマイクロサービスフレームワーク
  →Rabit MQとkafkaが現状プロダクトサポート。
 マイクロサービスで連携サービスが増えてくると、大変。フロントサービスが各サービスを呼ぶ。オーケストレーションスタイル。
HTTPだと、呼び出し元にサーキットブレーカですぐにレスポンスを返して伝える。遅い。結局密結合になっている。
 →イベントドリブン。メッセージングを使って連携する。
 元はPublish,先はSubscrivbe → Choreograhy Style
Persistent Pub-Sub > PersistentしてくれるのはMassage Broker
Consymer Group > スケールした場合に、どちらかにメッセージが届くように負荷分散できる>durable:必ずどこかには届く
Conumer Driven Contracts:受け取る側が送付側に仕様を表明する、ということ。
 >Spring Cloud Contract(DSLをGroovyで書く)

  • PDFとJava101 

ITextの開発者の方によるプレゼン。

iText側もApache PDF Boxを意識しているんだなあ、と感心。

Apache PDF Box:使い始めはかんたんだけど、PDFのSpecを知っている必要がある
iText:RowAPI/HighLevelAPIどっちもあり、便利とのこと。

はじめに · WildFly Swarm Tour

この枠は参加したいものがなかったので、ハンズオンに参加してきました。

まずはWildFlySwamのキャッチアップもしたかったので。CRUDアプリ作れるところまでできました。

WildFlyの特徴:高速な起動、高度な管理インターフェース、Module Class Loader
WildFly Swarm はWild Flyを組み込んだuber jar(実行可能jar)を作成可能
各種インテグレーション(例Netflix OSS)
最新版は2016.12.0(月次リリース)

 

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

Try Selenide

Codebone社(エストニア)製のライブラリ。
Selenideはシステムプロパティでブラウザを設定することができる。windowサイズなども
Jqueryライクにかけるのが特徴的。hamcrestのアサートっぽい。
Ajaxアサーションが楽。表現待ちのwaitを書く必要がない。(selenideないで再起処理されている)
AjaxまわりのAssertionも、Selenideは特に変わりなく実行できる。Seleniumだと非同期処理の場合はwaitを入れないといけない。
スクリーンショットで、selenideではHTMLファイルも保存される。
ラジオボタンのセレクト実装描きやすい
selenideのgithubwikiに比較表あり。
ぺージオブジェクトパターンで大量のlookupを回避
捜査対象のぺージを表すclassを作成し、そのclassを使ってテストを行う。
selenideではぺージオブジェクトの生成機能がある。アノテーションで定義。
headlessでテストしたい場合は、RemoteWebDriverとDockerを使うのが良さそう
SeleniumがDockerイメージを提供している。ただし、IEはない。

  • Payara microの設計と実装(蓮沼さん)

www.slideshare.net

Payara microとはPayaraのEmbeddedリリース
デプロイとアプリ実行を1コマンドで実施できる
Hezekcastでのクラスタリングがサポートされている
PayaraMicroのメインクラスがKernelを起動する。これは一般的なAPサーバと変わりはない
Ctrl+Cでのシャットダウンはshut down hookにて実現。
HazelcastについてはCLOVERというサイトを参照 d.hatena.ne.jp/Kazuhira/
Payaraの自動クラスタリングはHezelcastそのもの。ログがHezelcastそのまま。
Http Auto-binding機能。8080が使われてたら8081を使う、といった機能。デフォルトでは無効。
Maven リポジトリにある war をおとしてきて Payara にデプロイできる
Uber はウーバーと呼ぶ。
META-INF/deployの中のWARファイルを自分自身から取り出して、自分自身にデプロイする
Payaraは実行中にdomain.xmlを書き換えている。
メモリ内のDomainBeanをJAXBでファイルに書き出している。
Payara Micro APIとは?
組み込みサーバとして動くもの(WebProfile+Jbatchなど)

  • 全般

講演資料一式は以下にまとめられています。

GitHub - jjug-ccc/slides-articles-2016fall: JJUG CCC 2016 Fallの発表資料およびブログ記事まとめ

 

疲れてきたら、途中で帰ろうと思っていましたが、結局朝から晩まで参加しました。

(懇親会は不参加)

満足度は相当高いです。未参加の方、半年毎に開催されるので、今後の参加をおすすめします。

 

 

今更ながらGithub

Github良さげ。というか仕事で使わないとそろそろやばい。

  • コードレビューの習慣化
  • 他チームへのPullRequest
  • 他チームへのIssue
  • ソースのOpen化
  • 他ツールとの連携
  • ローカルリポジトリ

(Gitでも、というのばかりだけど気にしない)

新人入って来て、新規でソースコード管理リポジトリってものがあるよ、、と

伝えて、SVN、、、って。。ならないようにしたいですね。

 

ブランチ戦略は、よく考えます。

 

 

JavaOne2016開催直前、今年のJava関連ニュースまとめ

もうすぐJavaOne 2016ですね。

Javaに関するワールドワイドなイベント(お祭り)なので

多くの開発者が集まり、サプライズ発表あり(?)とが期待されます。

そんなJavaOneに参加される人のために、直前情報として残しておきたいと思います。

ただし、私は参加しませんが。。

そこで、JavaOneまでの2016年のJava関連の出来事を簡単にまとめておきたいと思います。

OracleJava9にてアプレット非推奨を発表:1月

blogs.oracle.com

JavaEEユーザーによる、JavaEE Gurdians結成:6月

www.infoq.com

JJUGも支援表明

Java EE Guardiansへの支援表明と活動紹介 | 日本Javaユーザーグループ

 

Java Gurdiansの活動を受け、 Oracleは声明発表。詳細はJavaOneで。

yoshio3.com

・ SpringOneにてTomcatの開発がJavaEE仕様策定が遅れていることにより、影響

www.infoq.com

JavaEEクラウドに向け、軽量化を望まれる

www.infoq.com

OracleJCP EC、 JavaEEの戦略を共有

www.infoq.com

OracleNetbeansApacheへ譲渡

forest.watch.impress.co.jp

JavaEEのリリースと、その参照実装のGlassFishと、その最新Glassfshを取り込んだNetBeansが同時にリリースされることは、今後なくなるんですかね。。。

・2017年3月リリース予定だったJava9、7月リリースに変更か?

Proposed schedule change for JDK 9

 

ネガティブニュースが多いですね。。クラウド対応、Micro化に期待しましょう。

JavaOneでは、Oracleの発表と共に、それを聞く聴講者のリアクション、反応に

注目です。

 

 

JavaDayTokyoの基調講演ネタ

参加はできなかったが、セッション内容をあらためて確認してみると、

損保ジャパンの役員が登壇したとのこと。

なぜ??と思っていたら、

 

ニュース - 損保ジャパン日本興亜がJavaで基幹システムを刷新、日本オラクルがPaaSや教育で支援:ITpro

 

のとおり、最近Oracle社と絡んで、且つJCP参加したから、だったのねー。(完全に推測)

windowsからDockerを触る

Docker技術のキャッチアップのため、

devcenter.magellanic-clouds.com

kitematic.com

を参考にDocker触れる環境を構築。

Jenkinsが入っているイメージを取ってきて、Dockerイメージとしてローカル上で動作させる、、なんてことも簡単!!

 

春のJava IDE祭り 〜激突!? 3大IDE!に参加してきました

溜まりに溜まった仕事を区切り(見切り?)をつけ、JJUGの勉強会に参加してきました。

テーマはIDEです。

 

春のJava IDE祭り 〜激突!? 3大IDE! 2016-04-25(月)19:00 - 21:00

  • inteliJ

 - Debug実行時にタイムリープ可能。ブレイクポイントおいたところから、少しステップ戻して、、とかが可能。
  http://blog.jetbrains.com/jp/2014/03/06/420
 - HTML編集時に、ブラウザで動的反映も可能。(Webサーバをブラウザでみているのと同じ感覚、)
 - JavaScriptサポートも。リファクタリングも可能。(文字列置換ではない)
 - git連携用のクライアントあり。
 - SQL実行も用意。SQL分の補完可能。テーブルリファクタもそこで可能。
 - Kotrinとの親和性も高い(JetBrains社製なので)
 - FWとの親和性も高い。SpringBootでダイアグラムでインジェクション先などの関係を図示化できる。
 - Java8には対応済。Java9についてもすでに対応済み。取り込み速度はメチャはやい。
 ‐ IDEAで後ろに.varとかつける記法:Postfix completion
  IDEA 13.1のPostfixコード補完 | JetBrains ブログ
  http://blog.jetbrains.com/jp/2014/03/19/433

 - EclipseはマーケットシェアNo1.  --2014年時点48%。IntelJ44%、NetBeans10%
 - Eclipseは遅い、重い、プラグイン選定がめんどいなどの課題が。。
 - エンタープライズで利用する理由
  - プラグインの充実、自分でも開発可能
  - 設定をInport/Exportできる → ルールを統一、底上げできる土台がある
 - なぜEclipseが重いのか?
  - プラグインが重い(数や、フックポイントなど)プレアデスも。
  - Incremental build(自動ビルドは狭く。有効にしたまま、ソースコード読み取り範囲を狭めるなど)
  - WTP(For Java EE):XMLの編集、バリデーションなど
  - その他:AntiVirusも大きな要員。Eclipse実行時にJarを読み込むので、Zip解析が走る
 -APサーバを利用するには?→Tomcatプラグイン。SpringBoot。Maven+RemoteDebug
 -JavaScriptEclipseではなく、VisualStudioCodeがおすすめ。
 - おすすめプラグイン:DB Viewer-ER Master、STS(Spring Tool Sxxx):MicroServicesのように複数同時にプロセス起動可能

 - Cloud IDE
   ‐Dockerコンテナイメージ
   -ブラウザで操作する
   ‐自動補完可能だが、まだ、ちょっとしたタイムラグあり(サクサクではない)

 ‐NetBeansチェコプラハ製。
 ‐もともとは学生プロジェクト。その後Sunがオープンソース
 ‐最新Javaテクノロジをいち早くサポートするのが最優先のゴール
 ‐英語版と日本語版を同時リリース
 ‐HTML5JavaScript開発もできる。フレームワークもそれなりに対応されている。
 ‐CSS3も。ブラウザ連携として、Chrome拡張や、Webkit統合も
 ‐ApacheCordova
 ‐Oracle JavaScript Extention Toolkit(Oracle JET)
  ‐Jquery,KnockoutJS,RequireJSベースのオープンソースライブラリ(3月にリリース済み)

  ‐NetBeans上でテンプレート読み込みの上、簡単にSPAアプリが作成可能。UIコンポーネントベース。