■

AWSの学習メモ

AWS Step Functions


必要になった背景：
    モダンアプリのベストプラクティス「Twelve-Factor App」
        - プロセスはステートレスかつシェアードナッシング
        - データはステートフルなバックエンドサービスに格納

    現代のアプリ -> 複数のプロセスが密接に関連
        - 複数のプロセスを同期実行させたい！
        - 複数のプロセスを並行実行させたい！
        - 条件分岐させたい！
        - 一定条件でリトライさせたい！
        - 例外やエラーを補足したい！
        - 状態を次のプロセスに連携させたい！

Step Functions
    - 分散アプリ・マイクロサービスの全体
    - ステートマシンでオーケストレーション可能
    - ワークフローが見やすい
        - ASL（Amazon States Language）と呼ばれるJsonで記述
        - ASLはrubyのチェックツールがある（cmd = gem install statelint）
    - 各ステップがログに出力

ステートマシン例：自販機
    1. 入金待ち
    2. ジュース選択
    3. ジュース出し/釣り銭だし

    -> こんな感じでプロセスを分離して連携している

ステートマシンから呼び出し可能なAWSサービス
    - Lambda：関数実行
    - DynamoDB：アイテム取得など
    - ECS/Fargate：ジョブ実行など
    - SNS：トピックへのメッセージ送信など
    - SQS：キューへのメッセージ送信など
    - Glue：ジョブ実行
    - SageMaker：トレーニングジョブ実行など
        ... etc
    - Activity
        サーバやコンテナに実装したアプリケーションからポーリングすることで、
        独自定義の処理を実行する仕組み
            - ECSやEC2からstep functionに対してポーリング

1日1%成長する

AWSの学習メモ

memo

Amazon Simple Notification Service (SNS)


VPCをAmazon SNSに接続するVPCエンドポイントを利用する

アプリケーション統合
    - cloudwatch event
    - step functions
        - DBへの書き込み成功時のみfun outとか
    - s3
        - オブジェクト作成をトリガーにfun outとか
    - SQS
        - snsは即時にmessage通知だが、即時性がなかったり信頼性を高めたい場合
        - キューをトピックで分けることが可能
    - Lambda
        - カスタマイズしたフィルターとして組み込むとか

mobile push
    - SNS
        - デバイストークンを運用者が管理
        - SMS通知は単方向
    - Pinpoint
        - デバイストークンはマネージド
        - 分析ダッシュボード有り
        - セグメントプッシュはプッシュ配信基盤不要
        - SMS通知は双方向


-> mobile pushを使う場合はpinpointがおすすめらしい
-> マーケティング利用だとよりpinpointほうがいい

特徴
    - アーキテクチャを簡素化
        - フィルターロジックをエンドポイント側で実装不要
    - 簡単なファンアウト
        - 複数の異なるエンドポイントにファンアウト可能
    - ワークロードのスケーリング
        - アプリケーションを動的にスケーリング
        - マネージド・サービス

 

1日1%成長する

AWSの学習メモ

memo

Amazon Simple Notification Service (SNS)

必要になった背景：
    -> システムが密結合してると管理しづらい
        -> 疎結合のサービスへ

    -> ただ、疎結合の場合は各処理が連携元に新しい処理を受け付けたかどうかの確認（ポーリング）
    　　をする必要が出てきた。

    -> これを中央から各処理へメッセージで一括送信する仕組み（fan out）で対応
        -> Amazon SNS


fan outの実現 => publish-subscribe(pub-sub)
    publisher：subscriberの存在は意識せず、メッセージをtopicへ投げる
    subscriber：購読したいtopicを選んでメッセージを購読する

    -> pub,subともにtopicのみ知っている状態
    -> 非同期のメッセージングモデル

    topic：pub subの間に立つことで疎結合を保つ
    -> オーナーが管理

Amazon SNSの機能
    - Mobile Push
        - セグメント毎のpushはAmazon pinpointの方が新しくそちらで網羅されているものもある
    - pub-sub
        - 通知もできるが、分散アプリの統合用途でも可能

awsのサービスがpublisherとして機能できる：
    cloudwatch events、step functions、api gateway、
    management console、command line interface、sdks、s3...etc

awsのサービスがsubscribeとして機能できる：
    lambda、sqs...etc

配信プロトコルなど
    http/https、email、sqs、lambda、platform application　endpoint、sms

アクセスコントロール
    effect:allowでprincipalのarnを指定する
    ActionでSubscribeとかを指定する
    Resourceで対象のtopicのarnを指定する

{
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:~user/mike"
    },
    "Action": [
        "SNS:Subscribe",
        "SNS:ListSubscriptionsByTopic",
        "SNS:Receive"
    ],
    "Resource": "arn~:BBtopic"
}

    mikeはBBtopicにSubscribe可能

FilterPolicyでSubscribe可能
Topicでエンドポイントのプロトコルで分けることが可能