AWS Innovate "クラウドネイティブ開発の今 ～ クラウドの特性をフルに活用した開発と運用 ～ (T1-1)"を見ていて

AWS イベント

AWS Innovateの"クラウドネイティブ開発の今 ～ クラウドの特性をフルに活用した開発と運用 ～ (T1-1)"を見ていた時のメモ

メモ

  • クラウドネイティブ
    • IaCでインフラ構築作業を自動化できる、反復できるのをポイントとしていた。これの前にあった課題は固定的なインフラ≒オンプレ。
      • （感想）作ったら作りっぱなし、なんて運用（あんまりよくないけど）だと反復できるほど作業がないから真価が発揮できないのかも。
        • たしかにそんなところがある。
          • それはそうなんだけど、自動化が価値をもつほど反復できる、それほどの数をどうやって集めるか？　順番が逆だけど、真価を生かすためには反復できるくらい数がないといけない。もちろん、そのために意味もなく数を増やすのはおかしい。
  • イベント駆動アーキテクチャ
    • コードとステートを切り離す（Queueを使って）
      • そして非同期で実行できるようにする
        • 壮絶な負荷があるときはモノをいう
  • MicroService or モノリシック
    • マイクロサービスは個々の独立性をがっちり維持しないといけない
      • ビジネス判断単位で分けること
    • 分散モノリス、モジュラーモノリス、といった方向性も提唱されている
    • Amazonのサイトはタイムセールとかアカウントとかのレベルで分割されているらしい
  • イベント駆動
    • Amazon EventBridge
    • ポーリングからプッシュ
  • データストリーム
    • Kinesis Data Streams
    • DynamoDB Stream
  • 数珠つなぎの処理（複数のマイクロサービスをまたがる一連の処理）をどうつなぐ？
    • Step Functions
      • ローコードに対応したらしい
  • リーンスタート
    • メインコンセプトを実現できる最小限の、ただしちゃんと動く、セキュアな、サービスを提供する、という考え方。
    • クラウドの価値はコストよりスピードアップや生産性の向上にある
  • MicroService or モノリシック （その２）
    • スタートアップではモノリシックのほうが断然いい
      • 発案者の考え方を全員が理解すべきだから。
        • 大きくなってきてコミュニケーションコストが上がってきたら分割を考える。
    • モニタリングがとても重要。ログの収拾も含め。
      • このあたりの実装を後回しにしてマイクロサービス化をすると、障害発生時にとても苦労する。
        • マイクロサービス化するならこのあたりまで全部含めてやるべき
    • 例）ヘッドレスコマース
  • AWS Well-Architected フレームワーク
    • どれも重要だが、わけても運用性が重要
  • DevOps
    • Metrics（チームの共通言語、重視する点など）について合意すべきである
    • さらに計測して見える化もすべきである
    • DevBizOps
      • 経営層、ビジネスのレイヤとも最適化されてしかるべき
  • CI/CD
    • CDのDはDeliveryとDeployの２つがある。間に人のチェックをはさむならDelivery、はさまずに一気にデプロイするならDeploy。

感想

  • マイクロサービス化がやたら流行りだけど、多くの場合、やるにしても分散モノリスやモジュラーモノリスが現実的なのかなという印象。特にスタートアップはモノリスのほうがいいんじゃないかという分析には完全に同意する。

    • 巨大なサービスを把握しきれる単位に分割して管理しよう、という発想は、サービスを分ける意外にも実現する方法があるはず。
    • メッセージングや協調動作など分散コンピューティングのために必要なモジュールや工夫を用意するのはとてもとても大変
      • そこまでしても割に合うほどのサービスは相当大きい。
        • モノリシックにしておきつつモジュール化するのが最適解なチームは多いのでは？
    • マイクロサービス化ありきでよく考えずにエイヤでやっちゃうのは絶対に間違っている。
      • 下手な分割の仕方をしたらマイクロサービスのデメリットしか残らない
      • モニタリングを適当にした状態でマイクロサービス化だけしたら悲惨だよね、という指摘もその通りと思う
        • でもそれってあるあるですよね、とも思う
    • 巨大すぎるシステムは保守運用しきれないのもたしかで、途中までモジュール化で凌ぎ、いよいよ巨大になってきたらサービスを分割する、くらいでいいんじゃないかなあ、と思える。

  • 新旧のサービスが同時並行運用できるのでないと切り替えが大変、という話がでてきた。やっぱりそれしかないんだなという感想。

    • 並行運用、そして切り替え。結局はこれがポイント。

  • DevBizOpsイカす。

    • 経営（ビジネス）→開発→運用と一気通貫で整合性を取った開発・構築ができるのは理想的だよなー。
      • そして自動化ももちろんできている、みたいな。
        • 自動化は、迅速化もあるけど、抽象的なアイディアを、抽象的なまま実現できるのが理想なんじゃないかと。
          • ローコードも本来それが理想なんじゃないかと思える、低スキルでも作業ができるのが云々じゃなくて。
          • AIがそういうより定型的な作業をよろしくやってくれるようになればいいんだけど、もう少しかかりそう。