先週のAWS関連ブログ〜4/24(日) - AWS Summit Chicago

どうも、セクションナイン吉田真吾@yoshidashingo)です。

先週は AWS Summit Chicago が開催され、たくさんの新機能が発表されました。前半でそこらへんを振り返ってみましょう。

ちなみに今年のグローバルサミットは昨年よりもさらに増え、36都市での開催となっています。個人的には北米・ヨーロッパ以外の都市で「リマ(ペルー)」「テルアビブ(イスラエル)」「台北(台湾)」「ソウル(韓国)」「北京(中国)」あたりは今後自分のビジネスとしても気になるところなので盛り上がり具合をチェックしたいなと考えています。 AWS Summit Online 2021 - セッション資料・動画公開中!| AWS

それではいってみましょう。

AWS公式

0. AWS Summit Chicagoまとめ

AWS Summit Chicagoでの発表内容がまとまっています。

www.slideshare.net

1. Amazon Cognito 向け User Pools

  • Amazon Cognitoにアイデンティティプール機能が追加された
  • 1アカウントで複数のUser Pool が作成でき、ひとつのプールはひとつのアプリケーションとひもづけることができ、アプリにはIDとSecretが払い出される。
  • プールのユーザーの属性情報には、既存で用意する16の属性(後から変更不可)と、カスタム属性が設定可能になっており、またMFAの設定を強制したり、サインナップ前や認証後にLambdaファンクションにイベントを発火させることができる

[New] Amazon Cognito 向け User Pools | Amazon Web Services ブログ

2. AWS Device Farm で実機にリモートアクセスして操作することが可能に

  • AWS Device Farmで実機へのリモートアクセスを行い画面操作することが可能に
  • 1デバイス最大60分間セッションが継続でき、その後自動的に停止される

AWS Device Farm のアップデート – デバイスにリモートアクセスしてインタラクティブなテストが可能に | Amazon Web Services ブログ

3. Amazon EBSに新たなスループット最適化ボリューム(st1)とコールドボリューム(sc1)が追加

  • HDDボリューム、マグネティックに2種類のオプションが追加された。どちらもルートボリュームではなく追加ディスクとしてのみ利用可能、サイズは500GBから16TB
  • gp2同様にバーストクレジットが適用され、算出はIOPSではなくスループットでされる(st1=500MB/s、sc1=250MB/s)、ただし1MB以下のブロックサイズも1MB分として計算されるので、有効活用のためには実際にOSが先読みでリードするサイズを1MBとして設定することがオススメ(※決してセクタサイズを1MBにするという話ではない)
  • 有効活用のために、OS領域とデータ領域をそれぞれ別の種類のEBSで構成するとよいはずなので、ためしにOS領域100GB、ログ領域500GBで試算してみると、以下のようにコールドHDDを使ったほうが安くなる
    • 従来:600GB(gp2)=$0.12/GB x 600=$72
    • ログアーカイブ最適化:100GB(gp2)+500GB(sc1)=$0.12/GB x 100 + $0.03/GB x 500=$27

余談ですが、PIOPSについては設定IOPS値に応じたコスト割合のほうが高めになるだろう(あくまで割合次第だが)から、ディスク分割はあまり有益にならない傾向だろうと思います、10000〜20000IOPSを目指さないなら素直に1TB gp2を使うのが安上がりです。が、ここらへんは自身の使い方に合わせて都度試算してみるといいです。

  • io1:3000IOPSで600GB(io1)=$0.142/GB x 600 + $0.074/PIOPS x 3000=$307.2
  • gp2:1TB(ベースラインで3000IOPS、バースト10000IOPS)=$0.12/GB x 1000=$120

Amazon EBSのアップデート – 新たなスループット最適化ボリュームとコールドボリューム | Amazon Web Services ブログ

dev.classmethod.jp

4. Amazon Kinesis アップデート – Amazon Elasticsearch Service との統合、シャード単位のメトリクス、時刻ベースのイテレーター

  • Kinesis FirehoseからElasticsearch Serviceへデータを連携できるようになった

f:id:yoshidashingo:20160425165620p:plain

  • シャード単位でPUTの成功バイト数やレコード数、シャードから受信したバイト数やレコード数、GetRecords呼び出しの遅延やリード/ライトのスロットリングの状況が確認できるようになった
  • 時間指定した中で最古のレコードを取得するような時刻ベースのイテレーター指定ができるようになったことでジョブのリランなどがやりやすくなる

Amazon Kinesis アップデート – Amazon Elasticsearch Service との統合、シャード単位のメトリクス、時刻ベースのイテレーター | Amazon Web Services ブログ

dev.classmethod.jp

5. AWSストレージアップデート – Amazon S3 Transfer Accelerationとより大きなSnowballをより多くのリージョンに展開

  • リージョン的に離れたS3バケットにデータを転送する場合に、エッジロケーションを活用することで近くのエッジにアップロードして内部的にエッジ間で転送を行いバケットに格納することで転送を高速化する(どのくらい効果があるか実際に計測できる)ことができるようになった。
  • 東京リージョン以外のバケットに転送する場合はおおむねエッジを使ったほうが高速化されるが、この機能を使うとアップロードするデータに対して$0.04/GB課金されるので、コスト見合いで検討するとよい。

f:id:yoshidashingo:20160425173432p:plain f:id:yoshidashingo:20160425173450p:plain

AWSストレージアップデート – Amazon S3 Transfer Accelerationとより大きなSnowballをより多くのリージョンに展開 | Amazon Web Services ブログ

  • AWS Import/Export SnowballがGovCloud、ノーカル、アイルランド、シドニーでも使えるようになり、キャパシティが従来の50TBのものに80TBのものが追加された(アイルランド、シドニー以外)。来年には残りのリージョンでも使えるようにしたいということで、東京リージョンで使えるようになったら日本中をSnowballを担いで飛び回れるように鍛えておきたい。

f:id:yoshidashingo:20160425180855j:plain

6. AWS Elastic Beanstalk がマネージドでプラットフォーム更新できるように

  • Beanstalkの環境のアップデートを自動的にメンテナンスウィンドウを指定して実行させられるようになった。
  • メジャーバージョンアップは自動実行されないので、その場合は手動でアップデートが必要。

AWS Elastic Beanstalk 管理されたプラットフォームの更新 | Amazon Web Services ブログ

AWS関連

7. Ops JAWS #5

  • 4/20(水)にOps JAWS #5が開催された

opsjaws.doorkeeper.jp

dev.classmethod.jp

自分のLTとしては(LTにしては量が多かったけど)、最近言われている「攻めの運用」といったあたりに対して、ITサービスマネジメントの考え方から、その進んだ実装の一つの例としてGoogle発の攻めの運用(+運用のための開発)スタイルであるSREについて、最近盛り上がり始めてるので整理してるのと導入するユーザーが増えてきているよという話をしました。

ポイントは、日本の多くのユーザーもすでに取り組んできた「ITサービスマネジメントシステム」について、それを「どう組織に実装するか」という点で、Googleが出した答えが参考になる(しかも彼らはすでに10年くらいはやってる)という点で、決して新しい職務ロールを創りだそうということではなく、サービスレベルの定義やPDCAサイクルを回すというITSMSの目標のために、現場で何をすべきか、自社のオペレーターとSREのスキルに何にギャップがあるかを見定めて必要なものをアドオンしていこう(特にツールの利用や作成、構築や監視や障害局所化などの自動化など)という話をしました。

www.slideshare.net

SREに関しては、今後もかなりの組織の運用改善の中で需要がありそうななので、引き続き組織への実装方法などを一生懸命考えていきたいなと思っています。

8. 第9回 コンテナ型仮想化の情報交換会@福岡

  • 上記勉強会のまとめエントリー
  • かっぱさんのECS、ECRの概要スライド
    • ECS=EC2にDockerをホストするためのスケジューラー+クラスタ管理サービス
    • ECR=S3上にDocker Hubのようなコンテナレジストリをホストできるサービス

inokara.hateblo.jp

speakerdeck.com

その他

9. 自然とそうなる開発チームをつくるいとなむ

  • 自然とそうなる開発チームを作るために、それを阻害する「場」を変えていこうという話
    • サービスへの興味、スキルアップ、チームへの協力を阻害してたものに気づく
    • 何度も繰り返し思いを伝えたり、自然とそうなってなかったことを気づかせる仕組み

speakerdeck.com

10. Infrastructure as Code 再考

  • Infrastructure as Code自体を取り巻く歴史的変遷や関連ツールなど、パラダイムのふりかえり
  • 当初のフォーカスが単純な「インフラの自動化」にあったところから、ソフトウェアシステムのベストプラクティスをインフラに適用するという(テスト駆動なども取り込み継続的インテグレーションといったワークフローとして適用する)考え方が一般的になってきている
  • Infrastructure as Codeなイベントをやるとのこと、楽しみ

mizzy.org

今週は以上です。