(動画まとめ)AWS re:Invent 2015: All You Need To Know About Auto Scaling (CMP201)


AWS re:Invent 2015: All You Need To Know About Auto Scaling (CMP201)

ELB

Auto Scaling group

Lounch Configration

  • どんなサーバを立ち上げるか
    • AMI, instance type, size
    • Security groupsm, SSH keys, IAM instance profile
    • User data
    • etc
  • AZとsubnetを除いたインスタンス立ち上げ時に必要な情報をすべて設定する

Golden image approch

  • Webサーバとかアプリとか設定とか全部作ったAMIを使う
  • 変更しまくるとAMIだらけになる
    • どれがどのバージョンかわかるようにする必要がある
    • OSのバージョンアップとかでもAMIをアップデートする必要がある

おすすめ

  • ベースAMIを作る
    • Webサーバとかログのエージェントとかいれとく
    • のこりはuserDataでやる
      • あとはChefとかpuppetとか
        • CodeDeployも
          • UserDataでcodedeployをインストールする感じ
    • バランスはチームの文化とかツールに依存する

インスタンスをターミネイトする時

  • 猶予期間だけセッションがはけるのをまつ

どのインスタンスたターミネイトされるか

  • Termination Policies
    • 常にAZ間のバランスを保つ
    • その上でどうターミネイトするか

いつスケールされるか

Scaling Plans

  • いつローンチされていつターミネイトするか
  • desired capacityよりローンチ済みのインスタンスが少なければ増えるし、多ければ減る
    • default: ヘルスチェックがこけたインスタンスを潰して新しくローンチ
      • desired capacityは固定
    • Manual scaling:desired capacityをAPIとかコンソールとかで変える
    • Scheduled: スケジュールでやる
    • Dynamic scaling: CloudWatchメトリクスによるスケール

ELBとASGのインテグレーション

  • トラフィックの分散
  • アプリケーションのエンドポイントを1つに
  • Connection drainingで登録解除中のインスタンスにリクエストを送らない
  • ELBのメトリクスでスケール
  • 複数のELBとあわせ動作できる
  • インスタンスの登録と解除をターミネーションとあわせて自動で行う
  • Auto Scaling groupでELBヘルスチェックを使える
  • Scaling policyでELBメトリクスが使える

AutoScalingの利点

  • 需要にあわせて自動でキャパシティを設定
  • 信頼性

可用性と信頼性

  • Health check

Health Checkの種類

  • EC2 instance status: EC2のステータス
  • ELB health check: ELBからのリクエストに対するレスポンスでチェック参考
  • Manual: 自分で定義したヘルスチェック
    • ディスクフルとかいろいろ

## AZごと死んだら * desired capacityを満たすように偏ることもある * AZが生き返るとリバランシングする

## Scaling policies * どのようにキャパシティが変わるか * desired capacityにあわせて * 個数で増減 * 割合で増減

スケジュールによるスケール

動的なスケーリングポリシー

  • 需要によるイベントをスケールのトリガーにする
  • メトリクスで需要を図る

CloudWatch

  • CPUとかネットワークトラフィックとか
  • アラーム = しきい値を指定した時間超えた
    • 指定した時間 = evaluation period
  • 一時的なCPUのスパイクでスケールさせたくない
  • アラームがAuto Scalingに通知してスケールをキックできる
  • 閾値超えからクールダウン終了までは別のアラームやスケールのイベントは起きない

めっちゃスパイクしたら間に合わなくね?

Step Scaling Policies

  • 同じポリシーで段階的なステップを定義できる
  • この段階的なステップでは追加のアラームやスケールが発生する
  • コンソールでも定義できる

warmup period

参考

Lifecycle Hooks

ユースケース

  • EIPのアサイ
  • DNSやらキューやらに登録
  • ターミネイトされる前にログをpull
  • ターミネイトされる前に問題の調査

どう動く?

参考

どうやる?

  • 通知先を作る(SQSかSNS
  • IAM roleを作る(Auto Scaling to access the notification queue/topic)
  • lifecycle hootとAutoScaling group, role ,通知先を連携
  • フックで動くコードを書く

LifecycleActionToken

  • アクションを続けたり破棄したりするのに必要
    • 次のステップにわたしてこれ継続よろみたいな

アクションはどう書く?

  • トークン、インスタンスID,その他パラメータの抽出
  • トークンはとっとく
  • なんかする
  • 終わったらCompleteLifecycleActionを送る
    • もっと時間が欲しければheartbeatを送る

SNSもいける

  • インスタンスがInService, Terminatedになってから送られる
    • Lifecycle hooksはその前の準備中に動く

スタンバイにできる

  • InServiceではない
  • Terminateもされない
  • InServiceに戻せる(API,CLI

ググった単語

  • descend
  • arbitrary
  • spectrum
  • flip side
  • grace period
  • drain
  • get rid of
  • accordance
  • sit on
  • whatever
  • boundaries
  • fleet
  • distribute
  • reliability
  • periodically
  • superfluous
  • counteract
  • use a neat trick
  • anticipate
  • predicable
  • disorient
  • investigate
  • abandon
  • extract
  • forensic

(動画まとめ)AWS Summit Series 2016 | Chicago - DevOps on AWS

AWS Summit Series 2016 | Chicago - DevOps on AWS


AWS Summit Series 2016 | Chicago - DevOps on AWS

ソフトウェアのリリースプロセス

Continuous integration

ソースコードをどこかにコミットして、テストして、ビルドまで。

Continuous delivery

ソースコードをどこかにコミットして、テストして、ビルドして、どこかの環境へのデプロイの準備ができるまで。

Continuous deployment

あらゆるコミットが本番環境に反映されるまで。

Continuous deliveryのメリット

  • 同じことなんかいもするのはだるい
  • コミットごとにテストを動かしてバグを対処したりできる
  • 週末とか夜のビルドをまたなくていい
  • 素早いアップデートの提供

AWS Codepipeline

  • 素早く信頼性のあるアプリケーションのアップデート
  • リリースプロセスの可視化
  • コードの変更ごとにビルド、テスト、デプロイ
  • サードパーティツールとの統合

AWS Codepilelineの要素

  • Pipeline
    • Stageで構成される
  • Stage
    • Actionで構成される
    • Transisionで違うStageとつながる
  • Action
    • 並行/直列実行できる

例の流れ

  1. GitHubにコミット
  2. Pipelineが変更をpullする
  3. S3にartifactsをPUT
  4. 次のステージに遷移しJenkins立ち上がってポーリング
  5. S3からjenkinsがartifactsを取得
  6. Jenkinsがビルド結果をS3にPUT
  7. JenkinsがPipelineに成功を通知
  8. 次のステージへ
  9. ビルド結果を取得
  10. Beanstalkに渡す
  11. Beanstalkがデプロイ

例ではCodepipelineは別ツールへのインターフェース

AWS CodeDeploy

  • どんなインスタンスへも自動でコードをデプロイ
  • 複雑なアップデートのハンドリング
  • ダウンタイムを避けたデプロイ
  • 言語やOSにかかわらずEC2やオンプレにデプロイ
  • サードパーティツールとの統合

appspec.yml

hooksでライフサイクルの定義ができる
起動時キックするスクリプトとかの指定
 → ELBに登録したりとか

ダウンタイム無しでのデプロイ

  • One at time
  • half at time
  • all at one

Lambdaによるアクション

  • 5分では処理できないタスクはContinuation Tokenで

わかりやすいJavaEEウェブシステム入門でいきなりハマった(macOS Sierra)

p17で最初のプロジェクトを実行したところでデプロイに失敗しハマる
具体的には以下のような状況

以下のページにてmacOS Sierraだとあかんとかなんとか
mac os Sierra でのGlassfish起動

記載の手順に従って、

  1. mac側のシステム環境設定→ネットワーク→詳細→プロキシ→自動プロキシ検出にチェック
  2. NetBeansNetBeans→Preference→「システムのプロキシ設定を使用」の隣にある「再ロード」クリック+その下の「接続のテスト」をクリック で、とりあえず起動できた。

アキネーターの作品版を作ったら金になるのではないかと思った

要件のイメージ(漫画版を仮定)

  • 〜な(抽象的な希望)漫画を探している、といった人がターゲット
  • 漫画喫茶に来たけどいまいち読みたい漫画がない人とか
  • 現実っぽいやつ or ファンタジーっぽいやつ、みたいな選択肢がでてくる
  • 選択肢はだんだん具体的になる(職業モノ or 趣味モノ、とか、人が死ぬかどうか?とか)
  • 最終的に選ばれた作品のAmazonへのリンクが出てきてアフェリエイトで稼ぐイメージ(音楽版だったらYoutubeとか、アフェリエイトあるのか知らんけど)

問題

  • 初期のデータをどう集めるか
  • 初期以降のデータをどう集めるか(どうやって属性とマッチさせていくか、利用者のデータ集めてく感じのような気はする)
  • そもそも選択肢と作品のマッチングをするのがしんどそう。精度が低いと需要ないだろうし

Springのセッターインジェクション

セッターによるインジェクション

@Component
public class SetterInjectionServiceImpl implements SetterInjectionService{

    //インジェクション対象
    private Test target;

    //セッターによるインジェクション
    @Autowired
    private void setTarget(Test target){
        this.target = target;
    }

    @Override
    public void show(){
        System.out.println("セッターインジェクションにてインジェクションされたインスタンス:" + target);
    }
}

呼び出し元のイメージ

       //このsetterにはすでにtargetが格納されている
        SetterInjectionService setter = context.getBean(SetterInjectionService.class);
        setter.show();

まとめ

  • DIコンテナに格納されたインスタンスは、@AutowiredのついたSetterによってフィールドに値が格納された状態のインスタンスとなる
  • というよりも、DIコンテナにインスタンスが格納されるタイミングで、@Autowiredのついたメソッドが呼び出される、くらいのイメージのがわかりやすいかも
  • その時、Autowiredのついたメソッドの引数は、インジェクションの対象となる
  • メソッドの引数に指定した値のインターフェースがインジェクションの対象にできない(Springの管理下に入っていない)と、起動時にエラーで落ちる

Webサイトを絵画調にするアプリ

昔Webサイトを油絵か何かで正確に模写するアーティスト的なのが出てくるのではと思った

機能イメージ

  • 画面からURLを入力する
  • アプリケーション側で、Selniumか何かでスクショをとる
  • 画像を変換して、油絵っぽくする
  • 画像を返却する
  • twitterか何かで拡散できるようにすると良い
  • ロスコ風とかゴッホ風とか選べたら楽しそう

JSTQB認定テスト技術者資格 Foundation Levelに合格しました

なんで取得したのか

体系的なテストの知識が薄いなと思ったから(お客さんと話していた時にC2カバレッジで〜〜という話がわからなくて困った)

自分の背景

開発の会社に新卒で入社して約3年

やった勉強

感想

  • 教科書を眺めた段階で一週間あればいけるなと思ってたら試験直前の一週間で自分の時間がほとんど取れない誤算があった
  • まとまった時間が取れるのが、試験前日の午前3時からという悲惨な状況
  • ここで教科書丸ごと読むのは一夜漬けでは無理だと判断し、シラバスに絞ったのは賢明な判断だったと思う
  • なんとなく(テスト界隈で)一般的な言葉をある程度網羅的に知れたのは良かったと思うが、シラバスわかりづらいというか、日本語怪しいところあって辛い
  • でもまあある程度体系的に(だいぶざっくりだけど)テストのことを知りたい、という場合には有用なのでは