メモ

途中で力尽きた

サーバレスアプリケーション
WEB API を作ってみよう
追記
- pythonで書いたら通った

サーバレスアプリケーション

やってみた経緯

転職活動用の職務経歴書修正と面接対策を始める
計5時間経過後、コレジャナイ感が出てくる
もやもやしたまま寝る
起床後、そうだ！サーバレスアプリケーションをやろうと思う

サービス思考アーキテクチャ(SOA)

まず、サービス思考アーキテクチャ（SOA）は、巨大なトヨタカーを作るのに代わって、たくさんの小さなおもちゃの車を作るような考え方だよ。大きなトヨタカーは一部が壊れると全部直さないといけないけど、小さなおもちゃの車は一つが壊れても他の車には影響しないんだ。

次に、ソフトウェアを作るときには、大きく3つの部分に分けて考えることが多いんだ。

1つ目は「プレゼンテーション層」、これはUX（ユーザー体験）の部分で、ユーザーが直接触れる部分だよ。つまり、おもちゃの車の色や形、どんなボタンがあるかなど、見た目や感じの部分だね。

2つ目は「ロジック層」、これはビジネスロジックの部分で、ソフトウェアがどう動くか、どういう計算をするかなど、おもちゃの車がどう動くかを決める部分だよ。

3つ目は「データ層」、これはデータ永続化の部分で、情報を保存したり、取り出したりする部分だね。おもちゃの車で言うと、エネルギーを蓄えておくバッテリーのようなものかな。

これらの層が分離していることが大切なのは、おもちゃの車の色を変えたいときにエンジンをいじらなくてもいいように、またエンジンを改良したいときに車体を壊さなくてもいいようにするためだよ。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャとは、まるで一つの大きなプロジェクトをたくさんの小さなプロジェクトに分けてしまうようなものだよ。例えば、大きなお城を一人で作るのは大変だけど、一部ずつ小さなブロックで作ると、どんなに大きなお城でも作れるようになるんだ。それぞれの小さなブロック（モジュール）は、自分の役割（機能）だけに集中するから、とても良くできているよ。

そして、それぞれのブロックは少人数の友達（開発チーム）で作れるから、みんながそれぞれのブロックを作って、後で全部をつなげれば、大きなお城（システム）ができ上がるんだ。

それに、友達の数や、みんなが得意なことによって、どんなブロックをどう作るか（アーキテクチャ）を決めることができるんだよ。みんなが楽しく、上手に作ることができる方法を選ぶべきだよね。

だから、マイクロサービスアーキテクチャは、みんなで一緒に作る大きなお城（システム）を作るのに、とても良い方法だと言えるよ。

仮想サーバへの依存

問題点	簡単な説明
どの規模のサーバが予算に見合うか	サーバの規模は必要なパフォーマンスと予算に大きく影響されます。大きなサーバはより多くのリソースを提供しますが、それに伴ってコストも上がります。そのため、予算に見合った適切なサーバの規模を選ぶことは難しい課題であり、サーバのスケーリング（規模調整）を手動で行う必要があります。
OSの設定をチューニングしてアプリケーションを最適化する必要があるか	仮想サーバを使用すると、サーバのOSの設定やチューニングが必要となり、これには深い技術的な知識が求められます。アプリケーションのパフォーマンスを最大限に引き出すためには、OSやネットワークのパラメータを適切に調整する必要があります。これは時間とリソースを大きく消費し、特に小規模な開発チームにとっては大きな負担となります。
ハードウェア故障への対応	物理サーバのハードウェアが故障した場合、それが修理されるまでサービスが停止する可能性があります。このような状況は、ビジネスに大きな損害をもたらす可能性があります。
リソースの無駄	仮想サーバは通常、固定的なリソース（CPU、メモリ、ストレージ）を提供します。しかし、すべてのアプリケーションが常に最大リソースを必要とするわけではありません。そのため、必要ないリソースまで確保するという無駄が生じ、結果的にコストが増大する可能性があります。
アップデートとパッチの管理	OSやミドルウェアのアップデートやセキュリティパッチの適用は、重要なセキュリティと性能の維持に不可欠です。しかし、これらを手動で行うことは時間と労力を大きく必要とします。

サーバーレスへ移行することでの改善点

問題点	改善点	簡単な説明
どの規模のサーバが予算に見合うか	オートスケーリング	サーバーレスでは、使用した分だけ料金が発生するため、必要なときに必要なだけのリソースを使用することが可能です。さらに、トラフィックが増えた場合に自動的にスケールアップし、減少した場合にはスケールダウンするため、リソースの使用効率が向上します。
OSの設定をチューニングしてアプリケーションを最適化する必要があるか	マネージドサービス	サーバーレスはマネージドサービスとして提供されるため、OSの設定やチューニングなどの運用負荷をAWSが負担します。これにより開発者はアプリケーション開発に集中することができます。
ハードウェア故障への対応	高可用性	サーバーレスアーキテクチャはデフォルトで高可用性を備えており、ハードウェアの故障が発生しても自動的にリカバリーします。これにより、ダウンタイムを最小限に抑えることができます。
リソースの無駄	効率的なリソース利用	サーバーレスでは使用したリソースのみを課金するため、必要ないリソースまで確保するという無駄がなくなります。さらに、リソースのスケールアップ・ダウンが自動で行われるため、リソースの使用が最適化されます。
アップデートとパッチの管理	メンテナンスフリー	サーバーレスではOSやミドルウェアのメンテナンス（アップデートやパッチの適用）がAWSによって自動的に行われるため、開発者がこれらのタスクを行う必要がありません。これにより、開発者はアプリケーション開発に集中することができます。

サーバレスへの進化

名称	簡単な説明
データセンター内物理サーバ	これは、コンピュータの大きな箱（サーバ）を自分のオフィスやビル（データセンター）に置いて運用する方法です。自分でサーバを管理するため、大きな箱が壊れたときや、アップデートが必要なときに自分で対応しなければなりません。
データセンター内仮想サーバ	これは、一つの大きな箱の中に小さな箱（仮想サーバ）をたくさん作る方法です。これにより、一つの大きな箱を上手に使うことができます。しかし、まだ大きな箱の管理は自分でしなければなりません。
クラウド上の仮想サーバ	これは、大きな箱を誰かに頼んで管理してもらう（クラウドサービス）方法です。自分のオフィスやビルに大きな箱を置く必要はなく、インターネットからどこでもアクセスできます。しかし、まだ小さな箱（仮想サーバ）の管理は自分でしなければなりません。
サーバレス	これは、箱（サーバ）のことを全く考えなくても良い方法です。自分はアプリケーションを作ることだけに集中でき、箱の管理は全て誰か（クラウドサービスプロバイダ）に頼むことができます。これにより、自分がやることは、アプリケーションを作り、使ってもらうことだけになります。

各デザインパターン

デザインパターン	簡単な説明
モバイルバックエンド (AppSync - Lambda - DynamoDB)	自分の部屋で遊ぶためのおもちゃ（データ）をどこからでも取り出せるようにする仕組み。AppSyncは、おもちゃ箱（DynamoDB）を開け閉めする魔法の鍵のようなもの。Lambdaは、鍵を使ってどのおもちゃを取り出すかを決める役割を担っています。
ワークフロー (StepFunctions)	長い旅のルートを作るみたいなもの。車（データ）がどの順番でどの道（ステップ）を通ってゴールに向かうかを管理します。StepFunctionsはそのルートマップの役割を果たします。
画像処理 (S3 - Lambda)	あなたが写真（画像）を家の壁（S3）に掛けたときに、魔法の絵画家（Lambda）がその写真を修正・加工すると考えてみてください。これが画像処理のデザインパターンです。
Amazon Alexaスキルチャットボット (Lambda)	Alexaと話すとき、あなたが何を言ったかを理解し、適切な返事をするためにはどこかにその知識が必要です。それがLambdaの役割です。あなたが「お天気は？」と聞けば、Lambdaは「今日の天気は晴れです」と返事します。

WEB API を作ってみよう

DynamoDB

動画の手順通りで登録完了

Lamdba

ここで力尽きた

node.jsのことが分からん
テストコードがエラーになるが解決しない

現状把握完了

ということで、必要なものをちょっと把握した

他のサイトを参考しよう

追記

pythonで書いたら通った

import boto3

def lambda_handler(event, context):
    dynamodb = boto3.resource('dynamodb')
    table = dynamodb.Table('user')

    # Extract the id from the path parameter
    id = event['pathParameters']['id']

    try:
        response = table.get_item(Key={'id': id})
        if 'Item' in response:
            return {
                "statusCode": 200,
                "body": response['Item']['name']
            }
        else:
            return {
                "statusCode": 404,
                "body": 'No item found with the specified key'
            }
    except Exception as e:
        print(e)
        return {
            "statusCode": 500,
            "body": 'Error in getting item from DynamoDB'
        }

結果：

各行の説明

import boto3

boto3は、Amazon Web Services (AWS) のPython SDKで、DynamoDBなどのAWSサービスとやりとりするために使用されます。

def lambda_handler(event, context):

これはLambda関数のエントリーポイントであり、AWS Lambdaから呼び出されます。eventはイベントデータ（API Gatewayからのリクエストなど）、contextはランタイム情報を含むオブジェクトです。

    dynamodb = boto3.resource('dynamodb')

これは、boto3を使用してDynamoDBサービスとやりとりするためのリソースオブジェクトを作成しています。

    table = dynamodb.Table('user')

DynamoDBリソースからuserという名前のテーブルへの参照を取得します。

    id = event['pathParameters']['id']

API Gatewayから送られてくるeventオブジェクトからidパスパラメータを取り出します。例えばURLが「/users/1」の場合、idは1になります。

    try:

エラーハンドリングのためのtryブロックの開始です。

        response = table.get_item(Key={'id': id})

DynamoDBテーブルから、キー（id）に対応するアイテムを取得します。

        if 'Item' in response:

取得したレスポンスにItemが含まれているか（つまり、指定したidのアイテムがテーブルに存在するか）をチェックします。

            return {
                "statusCode": 200,
                "body": response['Item']['name']
            }

アイテムが存在すれば、そのアイテムのnameとHTTPステータスコード200をレスポンスとして返します。

        else:
            return {
                "statusCode": 404,
                "body": 'No item found with the specified key'
            }

アイテムが存在しなければ、HTTPステータスコード404とエラーメッセージをレスポンスとして返します。

    except Exception as e:

tryブロック内で何か例外が発生した場合、それを捕捉します。

        print(e)

例外が発生した場合、その情報をCloudWatch Logsに出力します。

        return {
            "statusCode": 500,
            "body": 'Error in getting item from DynamoDB'
        }

例外が発生した場合、HTTPステータスコード500とエラーメッセージをレスポンスとして返します。

カニゲーム攻略日記ブログ

beatmaniaIIDXやハースストーンなどのゲーム攻略日記。主にまったり勢。２０１６年にIIDX皆伝になった

いまから始めるサーバレスアプリケーション途中までやってみた