« JAWS DAYS 2015 | トップページ | Java Day Tokyo 2015 »

2015/03/29

Developers.IO 2015 Developer Day

お話を聞きに行ってきました。

【クラスメソッドのAWSドッグフーディング】


クラスメソッドメンバーポータル(CMP)という、社内のプロダクトについての話です。


スライドは
http://www.slideshare.net/daisuke_m/20150329-developersio-2015-c1-aws


■役割

  • メンバーズのお客様向けポータル

  • 社内向け業務システム

  • AWS実験場


■CMPのテーマ

  • 完全AWSネイティブ

  • Java8+SpringFramework

  • single command deployとシステムポータビリティ

  • APIファースト


●完全AWSネイティブ

  • AWSの哲学・推奨に従う

  • 実装の都合を一方的に押し付けない

    • アプリとインフラで戦わない。都度最適解を追求する



  • AWSに寄り添う



  • SSKD
    small set of known developer
    ごく一部だけで使う、最適化されていないAPI



  • LSUD
    large set of unknown developer
    万人向けのAPI


現状のWebサーバは混在してるので、SSKDはシュリンクしていきたい



  • aws-sqsd

    • SQSへのポーリングを行うデーモン。WorkerはHTTPサーバとして実装しておき、sqsdからキューをPOSTする。

    • エラー時はなにもしないことで、SQSの方で勝手にキュー復活する。




  • ジョブスケジューラ
    遅延処理や定時処理

    • 処理の開始とトリガがHTTPリクエストではない。



無いので作ったBrian!
https://github.com/classmethod-aws/brian



  • Detailed Billing ReportのCSVが1年後には1日数十GB*数回…

    • よろしい、ならばEMRだ。Brianと組み合わせて取り込みジョブと集計ジョブを登録




  • CloudWatch-Alarm TIPS

    • RDSのFreeStorageSpace。ディスクが有限であるかぎり、DiskFullのリスクは消えない。

    • SQSのNumberOfMessagesPublished。Brianを利用する場合、メッセージがないのはおかしい。

    • SQSのApproximateNumberOfMessagesVisible。たまるということはWorkerのバグかキャパ不足。




  • CloudFormationTIPS

    • EnvironmentTypeパラメータ。local,development,productionでMulti-AZの有無、ストレージサイズなどを制御



●Java8+Spring Framework

  • プロジェクト構成

    • api

    • batch

    • worker

    • webapi

    • webclient

    • website




  • DomainDrivenDesign

    • Ubiquitous Language ぐらいは覚えとけ。




  • Spring Data

    • DDDのリポジトリパターンの実装フレームワーク

    • RDB用にはJPA実装。

    • MirageSQLを好みで採用。




  • 最近のJavaフレームワーク

    • PlayFramework

    • Dropwizard

    • Ninja framework

    • Spring Boot
      全部、アプリケーションサーバ不要。



ということは…



  • 1プロセスのための環境 ~Docker

    • 最近のJavaフレームワークはDockerと相性がよい。

    • ElasticBeanstalkもDockerをサポート




  • Beanstalk Appliation Bundle

    • アプリケーション一式を含むZIPファイル




  • SQSとSprignBatch

    • キューはタイミングの問題で複数回送信されることがあるので、メール送信のべき等性が難しい。

    • SpringBatchは同じIDで複数回実行できないので、ピタリとはまった。



●single command deployとシステムポータビリティ

  • Gradleでやってます。



  • Flyway~DBの進化的設計

    • スキーマにもバージョンを付与





  • システムポータビリティ

    • ビルドとデプロイの自動化

    • 自動化しない部分はポエム(文書)を書く

    • つまり、システムのすべてが記述されている! ←これ大事。




  • AWSにおけるシステムポータビリティ

    • 1つのアカウント内に複数の環境を構築できる。→本番/開発

    • あらゆるAWSアカウントに環境を構築できる。→例えば個人環境、SANDBOX環境

    • あらゆるリージョンに環境を構築できる、といいね。



●APIファースト

  • すべての機能はAPIを介して提供



  • HATEOAS

    • hypermedia as the engine of application state

    • 要するに、HTMLってインデックスがあって、そこからリンクをたどって参照するよね?JSONにも必要じゃないの?、という考え。人間にもやさしい。




  • Spring HATEOAS

    • SpringMVCの拡張




  • HAL

    • Hypertext Application Language




  • LSUDs向けAPIの問題点

    • 1ページ表示に必要なAPIコール数が増える

    • embedded resourceを活用することで、関連オブジェクトをいっしょに返すことも可能




  • REST without PUT

    • リソース自身の削除、アップデートなんて存在しない、という振りきった考え。




  • APIドキュメント

    • Swagger使え。Swagger Spring MVC使え。



試してみたいです。



  • APIファーストの結果、スタッフにCMP-API,SwaggerUI、aurlを配布したら

    • 恐ろしい勢いで業務効率化ハックが始まった。

    • HATEOASなどのおかげで、みんな自然にAPIを理解して使ってくれてる。

    • 初歩的な質問が来なくなった。




【Zombie Web - 倒れないWebシステム ~AWSでAuto-Defense~】

  • みんな大好きWordPress

    • 使う方も攻撃する方も




  • 攻撃は

    • 管理ページへの不正ログイン
      デザイナーなどが使うことが多いのでIP制限などしていない場合が多い。

    • プラグインを中心とした脆弱性を悪用した不正侵入。




  • 見た目の変わらない改竄が怖い。

    • バックエンドでウイルス配布サイトと通信してるのに気づかない



  • 2014年の不正送金は29億円。2013年の2倍。



  • サイト停止後はどうする?

    • ログがなくて調査てきない、いつから仕込まれていたかわからない。

    • 結局、OSから入れ直し。

    • 復旧まで時間がかかってビジネス止まってない?

    • 捨ててやりなおしたら?



ということで


●AWSを使って自動復旧・防御

  • webshellによるハックの実践。

    • 改善検知イベントで、health_check.htmlをmvさせてELBから外すとか、原始的な仕組みだった。




  • やっぱり、キモになるのは攻撃検知。

    • バックドアへのアクセス検知だけではすり抜けるので、ファイル改竄なども含めた複数箇所でのトラップが必要。

    • Firewall、IDS/IPS、ウイルス対策、変更検知



【アプリケーションコンテナとAWSの話】
ElasticBeanstalk 押しの話。



  • 従来のアプリコンテナの課題

    • 対応するランタイムしか利用できない

    • モジュールやプログラムの追加に制限がある




  • Dockerとは?

    • OSSのアプリコンテナエンジンとその周辺サービス

    • 実体はchroot&Cgroups+UnionFS+NAT Networking




  • メリット

    • ランタイムがコンテナに同梱される。ただしサイズは大きくなる

    • ポータビリティが高い

    • コンテナ/アプリの起動が早い



■AWSでDockerを実行する3つのサービス

  • EC2

  • EC2 Container Service(ECS)

  • Elastic Beanstalk(EB)


●Docker on EC2

  • yumで入れてください

  • コンテナ管理ソフトが必要。

    • CoreOS+Fleet、Kubernetes、Docker Swarm



●EC2 Container Service

  • Dockerクラスタ管理をサービスとして提供

  • 操作はAWS CLIから。GUIはまだない。

  • まだプレビュー。

  • スケジューラ、ELBとの連携、GUIは今後追加予定


●Elastic Beanstalk

  • PaaSのように、Git拡張、Eclipse連携でAWS環境にデプロイできる

  • EC2インスタンスの他、ELB+AutoScaling+RDSもまとめて作ってくれる

  • 昨年4月にDockerサポート

  • Dockerによって、EBのランタイムが一気に増える契機になった。

  • 長らく、1インスタンス1コンテナという制限があったが、3日前(3/26)にマルチコンテナに対応した。

  • BeanstalkインスタンスでECSエージェントを実行、コンテナ管理部分をECSが担当。

    • ECSが動いてるので、申請が必要。東京リージョンでは選択不可



●EB Dockerのマルチコンテナ対応

  • AutoScalingでも、1インスタンスごとのコンテナ構成は全インスタンス共通

  • 現時点でEB CLI 3.xは非対応


●Dockerクラスタ vs EB Docker

  • EC2の課金体系にマッチするのはEB Docker

    • Dockerクラスタは実行コンテナ数によらず、EC2インスタンスのタイプ/数で課金される



  • リソース管理コストもEB Dockerの方が楽。



  • Dockerクラスタが向くのは…

    • マルチテナント展開など、コンテナ自体を細かく管理

    • コンテナの起動スピード

    • サービサー向け



のような要件


●まとめ

  • Elastic Beanstalk Docker いい!
    ただし、

    • 一般的なDockerクラスタモデルとは違う

    • AWSの特徴にマッチした形態になっていて、開発者向け。


|

« JAWS DAYS 2015 | トップページ | Java Day Tokyo 2015 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: Developers.IO 2015 Developer Day:

« JAWS DAYS 2015 | トップページ | Java Day Tokyo 2015 »