Docker から Lambda へ: AWS 管理者の Python アプリケーションへの取り組み

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

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

私の旅

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

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

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

「趣味が仕事になる」という難問

これを自宅サーバーで実行するのは非効率だと感じました。 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 アーキテクトの観点 (および料金計算ツール) は、サーバーレス アプローチを提案しました。

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

これにより、私はサーバーレスのウサギの穴に落ちました。 私にはこれまでにサーバーレスの経験がありました。つまり、妻と一緒に温度追跡プロジェクトを行い、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 アプリケーションに拡張することは、困難であることが判明しました。

サーバーレスの魅力

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

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

データベースの決定

Lambda での SQLite の制限により、SQLAlchemy の知識との互換性を維持しながら 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>

ラムダ学習曲線

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

<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 関数の構造が改善されました:

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

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

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

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

<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>

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

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

<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>

結果

数週間の作業の後、私のアプリケーションはサーバーレスになりました。 セキュリティ上の懸念があるため、オンラインには保存しませんが、貴重な教訓を学びました:

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

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

以上がDocker から Lambda へ: AWS 管理者の Python アプリケーションへの取り組みの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。