2017-07-01

JustTechTalk#09に参加してきました

2017年06月30日にありました、
JustTechTalk#09 Webサービスを支える「インフラ」の運用事例とベストプラクティス
に参加してきました。

※資料は公開され次第、リンクを追記します

最近、AWSを活用するケースが多いと思うのですが、やり方が多く、

どうするのが良いのか迷う場面が多くなりましたので、その一助になれば良いかと思い、参加です。

justsystems.doorkeeper.jp

特に、案内の中にもあった、

運用テーマ
・AWSセキュリティ要件を考慮した最適構成
・AWS構築/デプロイの自動化
・AWSコストダウンと自動バックアップ
・早期発見/復旧でAWSシステム安定運用

運用ツール
・Ansible/Packer/Terraform/Fluentd
・GitLab/Jenkins
・AWS CodeDeploy/
・AWS CloudTrail/ColudWatch/EC2 Systems Manager
・AWS Athena
・Zabbix

あたりの話を聞きたかったのです。

JustTechTalkへの参加は初めてでしたが、参加者の年齢層は結構バラバラで

若い人たちばかり、、といった感じではなかったです。

その分、地に足ついた内容といった印象を受けました。

①DevOpsをどのように進めたか
元々は開発部門と基盤・インフラ部門が分かれていた
→組織改編があり、詳細設計・開発構築時には同じ組織になった。
ただし、そうなると、インフラ担当がアプリケーションの中を理解する必要がある。
開発部門も同様に、インフラのことを知らなければいけない。
→結局組織は一つだが、なんとなく担当は別れるので、結局、仲を取り持つ、

両方（インフラとアプリ）を知っている人が重要。

チーム一体化のデメリット
→管理者、評価者が管理、理解する範囲は増え負担が増える

AWS管理のポイント：AWSアカウントは単一だと危険。
カオスになってくる。（セキュリティグループ、IAM、ACL,,,)
作業ミスで破壊される可能性。

terraformでAWSの構成を作成。
→terraformは状態ファイルを持つため。手作業で基盤を変えた場合は差分が発生するため注意
Ansibleなどツール自体の不具合に注意。まだまだある。Bug情報をwatchする必要あり。（これは何にしても、、ですが、）

ユースケース、パラメータ的網羅テストもアプリケーション同様に考え、テストを実施する

今後はログの調査、分析の簡易化、仕組み化を便利にするように推進中。
Amazon CloudwatchLogis,Kibana,を利用。
現状はzabbixを使っていて問題は発生していないが、ノウハウをもっている人に依存してしまっているという課題を認識しており、makalel等に移行するかを検討中。

②AWS運用における最適パターン
「サービスの責任はアプリケーション開発者が持つ」
梵字徹底：当たり前のことを確実にやる
AWSのベストプラクティスを参考に、実践例も交えて検討する。
コードで確実に、同じ結果にすることが大切

AWS構築、デプロイの自動化
JenkinsからGitLab-CIに。Dockerベースなので良い。（自分にはその良さがわかりませんでしたが）
導入コストが低く、保守も簡単。たまにバグを踏むとのこと。。

③ログ管理のベストプラクティス

AWS桑野さん（前職はCA）

CloudWatchLogs,CloudTrail:APIを操作を記録するサービス。
管理コンソール、APIなどが対象。誰がいつAPIを発行したのか、されたのか。

リアルタイム処理が不要であれば、バッチ処理
必要であれば、Streamで処理。
ログ収集サーバに集めるとそこがSPOFになるしスケールしづらい。そこでミドルウェアアプリケーションの利用：Fluentd, Logstatsh, Flume。
バッファリングしてくれるFluentd（OSS）が便利。
Fluentdを多段で組むのが基本スタイルとなる。Aggregation Serverを中間に立てるイメージ。

Kinesis FirehouseでFluentd→S3の連携をEC2無しに実現。
今年のAWS Summitで後２ヶ月ぐらいで東京リージョンに来ると発表されていたので、もうすぐ使えるようになるはず。
直接送れば Aggregation Server不要でシンプルな構成に。Aggregation Serverのスケールアウトも気にしなくていい。

ただしKinesisからログを取得するにはLambdaかEC2が必要→そこで Kinesis Firehose！

Fluentdから直接S3に送ると変更するのが大変、特に書けなかったときのリトライ処理が面倒。

全てのログをS3に貯め続けることが大切。データレイク化の発想。
Amazon athena：S3においたデータに直接SQL実行可能
tokyoでも最近から利用可能になった。
スキャンしたしたデータ1TBあたり5ドルだが、一度スキャンしたものをまたS３に入れて

それを見たり、それからRedShiftで活用したりと節約ポイントはある模様。

まとめ

現場でどうやっているか、何に困ってどう対策したかなどが、かなり勉強になりました。開催ありがとうございました。

2017-06-03

MEANスタックのExpressについて調べたまとめ

ちょっとしたきっかけで、調べた個人メモ。

Node.js：サーバサイドJavascriptの実行環境。
ExpressはそのNode.jsでのフレームワーク

REST　APIも簡単に作ることができる。JSONを扱いやすい（JavaScriptとの相性が良い）
app.jsの記載例

const app = express()

// GETリクエストに対処
app.get([url], (request, response) => {
// requestをもとに処理をし、クライアントにresponseを返す
})

// POSTリクエストに対処
app.post([url], (request, response) => {
//
})

// PUTリクエストに対処
app.put([url], (request, response) => {
//
})

// DELETEリクエストに対処
app.delete([url], (request, response) => {
//
})

// ポートを指定してアクセスを受け付ける
app.listen([ポート番号], callback)

nodeを使うため、npmを活用でき、様々なツールも利用できる。

ExpressではテンプレートエンジンをJadeやEJSといったモジュールから選択することができる。

今回はHTMLがそのまま利用できるEJSが良い。EJSもNPMパッケージとして提供されている。npm installコマンドでインストール。

日本語サイト(公式)
http://expressjs.com/ja

英語サイト　resourcesなどで日本語版との差分が顕著
http://expressjs.com/en/resources/middleware.html

Qiita：ゼロからはじめるExpress + Node.jsを使ったアプリ開発
http://qiita.com/nkjm/items/723990c518acfee6e473

Node.js+express+MongoDB+Mongooseで簡単なjsonサーバを構築するメモ
http://qiita.com/tdomen/items/4ecb15f25bf9c3652f59#_reference-403ebec67691a94893a1

DBアクセス

node.js から MongoDB にアクセス (Mongoose の紹介)
http://krdlab.hatenablog.com/entry/20110317/1300367785

node.js から MongoDB にアクセスためのライブラリに Mongoose がある
O/R Mapper っぽく使えるように設計されており，既存の O/R Mapper を使ったことがある人にとっては，比較的わかりやすい仕様．

Node.js + Express 4.x + MongoDB(Mongoose)でRESTfulなjsonAPIサーバの作成を丁寧に解説する．+ テストクライアントを用いたAPIテストまで
http://qiita.com/shopetan/items/58a62a366aac4f5faa20

レイテンシをあげたい場合は、、、Socket.IOを使う
Node.js、Socket.IO、MongoDBでリアルタイムWeb
http://www.atmarkit.co.jp/ait/articles/1210/10/news115.html

APIのテストをするには、、（内容古い？今はもっと良いものあるかも）
Postman - Google Chromeを使ったWeb APIテストクライアント
http://www.moongift.jp/2014/05/postman-google-chrome%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9Fweb-api%E3%83%86%E3%82%B9%E3%83%88%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88/

React+Redux+Express+MongoDBでものすごくシンプルなCRUDアプリをつくる
http://qiita.com/hoture/items/573247b12ff0bc4e5d3c#%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E5%81%B4

MEANのホームもあった。
http://mean.io/

2017-03-25

リアクティブ入門

勉強中。このスライドがわかりやすい。

Spring 5に備えるリアクティブプログラミング入門 from Takuya Iwatsuka

www.slideshare.net

Springはあまり知らないけれども、前半部分の触りだけでも、すごくまとまっている。

2017-03-12

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

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

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

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

充実した1日でした。

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

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

資料

サーバーレスでシステムを開発する時に⼤切な事 from Hiroyuki Hiki

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

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

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

EC2:1インスタンスで多数のAPI

Lambda:1対1

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

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

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

- Fintech 最前線渥美さん

立ち見も出るほどの盛況ぶり。200人ぐらい。
メガバンクも利用。日経からの３つの記事がでた。自身も勉強会で訪問した。
新規案件のうち５０％、既存システムは更改時にクラウド化。→クラウドファースト
グループ共通の共通基盤とする。
３システムが稼働中。
10件弱開発中。20件検討中。
2017年中にAWSの資格習得者を30人育成
FIN TECH
リーマンショック、エンジニアが流出
格差拡大、Unbank、金融機関への不信
新テクノロジーとスタートアップが始まり
会議ではこの２−3年で投資が急激に拡大
海外では、既に金融機関を脅かしている
金融庁の危機感。→ワーキンググループを組成。
銀行のビジネスモデル→ソフトウェア産業化、APIエコシステム化
FISC安全対策基準第８版で（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について５０分説明しているものがあり。
コンテナに適した

チーム体制とデリバリー

アプリケーション(これが一番大事。ログを適切に吐くとか。IPが固定されていることが前提の作りとか。ディレクトリにここにファイルがあること前提とかにしない)

運用（管理タスクもコンテナに）

インフラ構築

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

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

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

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

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

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

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

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

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

2016-12-04

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

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

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

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

www.java-users.jp

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

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

speakerdeck.com

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

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

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

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

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

SIerもはじめるわたしたちのDevOps #jjug_ccc from Mizuki Wada

www.slideshare.net

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

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

Spring Cloud Stream

Event Driven Microservices with Spring Cloud Stream #jjug_ccc #ccc_ab3 from Toshiaki Maki

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 Swamハンズオン

はじめに · 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のgithubのwikiに比較表あり。
ぺージオブジェクトパターンで大量のlookupを回避
捜査対象のぺージを表すclassを作成し、そのclassを使ってテストを行う。
selenideではぺージオブジェクトの生成機能がある。アノテーションで定義。
headlessでテストしたい場合は、RemoteWebDriverとDockerを使うのが良さそう
SeleniumがDockerイメージを提供している。ただし、IEはない。

Payara microの設計と実装（蓮沼さん）

Payara micro-internals from 賢志蓮沼

www.slideshare.net

Payara microとはPayaraのEmbeddedリリース
デプロイとアプリ実行を１コマンドで実施できる
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など）