Python スクリプトからサーバーレス AWS へ: 私の投資ポートフォリオの旅

AWS 自動(dòng)化用の単純な Python スクリプトから始めて、徐々により複雑なプロジェクトに進(jìn)化しました。 3 か月前、私はメタクラスをほとんど理解していませんでした。これで、本格的な投資ポートフォリオ マネージャーを構(gòu)築できました。

私の旅

私は AWS 自動(dòng)化 (あの悪名高い「すべてを行う」スクリプトを含む) に Python を長(zhǎng)年使用してきた結(jié)果、適切なアプリケーションを構(gòu)築することができました。 過(guò)去のスクリプト、スタック オーバーフロー、クロードの AI 支援を活用して、ついにソフトウェア開(kāi)発の原則を理解しました。

アプリのスクリーンショット (実際の投資ではなく、シード データ)。

投資ポートフォリオの Excel スプレッドシートを手動(dòng)で更新することにうんざりし、プロセスを自動(dòng)化しました。 この Python アプリケーションは、ポートフォリオを管理し、取引を追跡し、配當(dāng)を処理し、さらには価格を自動(dòng)的に更新します。 當(dāng)初、ホームサーバー (Flask バックエンド、React フロントエンド、SQLite データベース) 上の Docker で美しく動(dòng)作しました。

「趣味が仕事になる」という難問(wèn)

これを自宅サーバーで実行するのは非効率だと感じました。 AWS のプロフェッショナルとして、ハードウェア上でコンテナを管理するのは直感に反するように思えました。解決策は明白だと思われました: ECS です。 docker-compose ファイルは既にありました:

<code>services:
  backend:
    build: ./backend
    container_name: investment-portfolio-backend
    environment:
      - DB_DIR=/data/db
      - LOG_DIR=/data/logs
      - DOMAIN=${DOMAIN:-localhost}
    volumes:
      - /path/to/your/data:/data
    networks:
      - app-network

  frontend:
    build:
      context: ./frontend
      args:
        - DOMAIN=${DOMAIN:-localhost}
        - USE_HTTPS=${USE_HTTPS:-false}
    container_name: investment-portfolio-frontend
    environment:
      - DOMAIN=${DOMAIN:-localhost}
      - USE_HTTPS=${USE_HTTPS:-false}
    ports:
      - "80:80"
    depends_on:
      - backend
    networks:
      - app-network</code>

しかし、AWS アーキテクトの観點(diǎn) (および料金計(jì)算ツール) は、サーバーレス アプローチを提案しました。

• 価格は毎日更新され、アクセス頻度は低いため、24 時(shí)間年中無(wú)休のコンテナを避けることが推奨されます。
• 靜的フロントエンド ファイルは S3 Web サイトのホスティングに最適でした。
• API Gateway と Lambda は API 呼び出しを処理します。
• Aurora Serverless はリレーショナル データに適していました。
• DynamoDB は価格履歴を保存できます (ただし、この段階には達(dá)していません)。

これにより、私はサーバーレスのウサギの穴に落ちました。 私にはこれまでにサーバーレスの経験がありました。つまり、妻と一緒に溫度追跡プロジェクトを行い、KNMI データを使用して、クラフト プロジェクト用に色分けされたテーブルを生成しました。

<code>| Date       | Min.Temp | Min.Kleur   | Max.Temp | Max.Kleur   |
----------------------------------------------------------------
| 2023-03-01 |   -4.1°C | darkblue   |    7.1°C | lightblue  |
| 2023-03-02 |    1.3°C | blue       |    6.8°C | lightblue  |
...</code>

このプロジェクトは、日付パラメータを受け取り、ローカルまたは Lambda/API ゲートウェイ経由で実行されました。 これを SQLAlchemy、バックグラウンド ジョブ、複雑な関係を使用して完全な Flask アプリケーションに拡張することは、困難であることが判明しました。

サーバーレスの魅力

コンテナ化されたアプリケーションはうまく機(jī)能しましたが、サーバーレス サービスの魅力は強(qiáng)力でした。 自動(dòng)スケーリングの可能性とコンテナ管理の排除は魅力的でした。

そこで、サーバーレス環(huán)境用にアプリケーションを再設(shè)計(jì)しました。 元のプロジェクトには 2 か月かかりました。これなら簡(jiǎn)単だろう...そう私は思いました。

データベースの決定

Lambda での SQLite の制限により、SQLAlchemy の知識(shí)との互換性を維持しながら PostgreSQL Aurora Serverless を検討するようになりました。 デュアルハンドラーを作成しました:

<code>services:
  backend:
    build: ./backend
    container_name: investment-portfolio-backend
    environment:
      - DB_DIR=/data/db
      - LOG_DIR=/data/logs
      - DOMAIN=${DOMAIN:-localhost}
    volumes:
      - /path/to/your/data:/data
    networks:
      - app-network

  frontend:
    build:
      context: ./frontend
      args:
        - DOMAIN=${DOMAIN:-localhost}
        - USE_HTTPS=${USE_HTTPS:-false}
    container_name: investment-portfolio-frontend
    environment:
      - DOMAIN=${DOMAIN:-localhost}
      - USE_HTTPS=${USE_HTTPS:-false}
    ports:
      - "80:80"
    depends_on:
      - backend
    networks:
      - app-network</code>

ラムダ學(xué)習(xí)曲線(xiàn)

Flask アプリケーションを Lambda 関數(shù)に変換することは、予想よりも複雑でした。 私の最初の試みは不器用でした:

<code>| Date       | Min.Temp | Min.Kleur   | Max.Temp | Max.Kleur   |
----------------------------------------------------------------
| 2023-03-01 |   -4.1°C | darkblue   |    7.1°C | lightblue  |
| 2023-03-02 |    1.3°C | blue       |    6.8°C | lightblue  |
...</code>

保守性を向上させるために、デコレーターを作成しました。

<code>@contextmanager
def db_session():
    # ... (code for environment-aware database session management) ...</code>

これにより、Lambda 関數(shù)の構(gòu)造が改善されました:

<code># ... (initial, inefficient Lambda handler code) ...</code>

しかし、これは元の Flask ルートを壊してしまいました。 新しいデコレーターにより、二重の機(jī)能が有効になりました:

<code>def lambda_response(func):
    # ... (decorator for cleaner Lambda responses) ...</code>

サポート機(jī)能により一貫した応答が保証されます:

<code>@lambda_response
def get_portfolios(event, context):
    # ... (simplified Lambda function) ...</code>

これにより、Flask と Lambda の両方で同じルートを使用できるようになりました:

<code>def dual_handler(route_path, methods=None):
    # ... (decorator for both Flask routes and Lambda handlers) ...</code>

フロントエンドのシンプルさ

フロントエンドは簡(jiǎn)単でした。 S3 靜的 Web サイト ホスティングと CloudFront により、簡(jiǎn)単な導(dǎo)入が可能になりました。 単純なスクリプトでフロントエンドを S3 にアップロードし、CloudFront キャッシュを無(wú)効にしました。

<code>def create_lambda_response(flask_response):
    # ... (function to convert Flask response to Lambda response format) ...

def create_flask_request(event):
    # ... (function to convert Lambda event to Flask request) ...</code>

結(jié)果

數(shù)週間の作業(yè)の後、私のアプリケーションはサーバーレスになりました。 セキュリティ上の懸念があるため、オンラインには保存しませんが、貴重な教訓(xùn)を?qū)Wびました:

1. Python の機(jī)能はスクリプト作成を超えて拡張されます。
2. AWS 無(wú)料利用枠は開(kāi)発にとって非常に貴重です。
3. CloudWatch Logs はデバッグに不可欠です。
4. 「適切な」方法が常に AWS の方法であるとは限りません。

これを繰り返しますか?おそらくそうではありません。 しかし、その旅は私に Python とデュアルスタック開(kāi)発について教えてくれて、やりがいのあるものでした。 私の投資ポートフォリオ マネージャーはプライベート ネットワーク上で安全に動(dòng)作するようになりました。

以上がDocker から Lambda へ: AWS 管理者の Python アプリケーションへの取り組みの詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語(yǔ) Web サイトの他の関連記事を參照してください。