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を使うというのが勉強になった。オンプレでのシェルやバッチ相当の汎用性がある。