https://developersblog.dmm.com/entry/2024/02/28/110000

サムネイル

こんにちは。ITインフラ本部 SRE部の河村です。私が所属するSRE部では、Site Reliability Engineeringの観点から、グループを横断してシステムの信頼性を向上させる取り組みを行っています。いわゆるCCoE(Cloud Center of Excellence) としての活動も行いながらグループ内のパブリッククラウド利活用の推進・改善も担当しています。今回はアカウント管理効率化の一環として、AWS Organizationsを用いて通知処理をSlackへ共通化した話をご紹介します。

DMMにおけるAWS利用状況

DMMでは、多くのサービスがAWSで稼働しています。各サービスは、サービスごと（あるいは環境ごと）にAWSアカウントを保有しており、担当するエンジニアリングチームによって開発・運用が行われています。技術選定やアーキテクチャなどはチームごとに委ねられていることから、エンジニアにとっては自由度が高く、裁量を持って作れる良さがあります。同様にアカウント管理や運用効率化のために必要な諸タスクもチームごとに委ねられていることから、同じようなものを各チームが個別実装しているという状況が続いていました。

サービス担当のエンジニアリングチームは、本来はサービス開発や運用に集中すべきで、可能な限り処理の共通化が望ましいです。そこでAWS Organizationsを用いて、ニーズが高い“通知処理の共通化”、提供を推進しています。

共通処理の実装

AWSでは、複数のAWSアカウントを組織単位で管理できる「AWS Organizations」というサービスが用意されています。組織内のアカウントをグループ化し、ポリシーの適用、リソースの一元管理を組織全体で行えます。例として“AWS利用料金通知の実装”を紹介します。システムコスト通知は、サービス運用において重要な情報であり、また共通化ニーズが非常に高いです。

アカウントごとに通知内容をカスタムできるように設定ファイルに必要な情報を持たせ、それを元に通知処理を行うことにします。設定ファイルに保存されたアカウント情報などを元にコスト情報を並列処理で取得し、通知する処理を実装します。このような処理実装にはさまざまな手法があると思いますが、「AWS Step Functions」「AWS Lambda」を使うと、手軽にWorkflowを実装できます。

設定ファイルは以下のイメージです。通知内容をアカウントごとにカスタムできるようにパラメータを用意します。「週次でコスト通知してくれるとうれしい」というニーズも存在するので、事業別に設定できるように設定ファイルはGoogle Spreadsheetなどを使って事業側で編集と反映を可能にしています。

[
    {
    "AccountId": "___your_account_id___",
    "Description": "hogehoge service staging env",
    "ChannelIds": [
        "ABCDEFGHI"
    ],
    "Currency": "JPY",
    "Granularity": [
        "DAILY"
    ],
    "CostTags": ""
    },
    ...(略
]

Step Functionsで作るWorkflowは以下のようになります。設定ファイルに記載された対象アカウントをStep FunctionsのMapステートメントで呼び出し、並列実行します。今回のユースケースでは対象データが大量ではないものの、StepFunctions + Lambdaの組み合わせは、大規模データ処理に対応可能なソリューションのひとつとして注目しています。今後、ほかのユースケースでも活用できそうです。

workflow_screenshot

コスト取得

AWSのコスト情報は、「AWS Cost Explorer API」を使って取得できます。AWS Organizationsメンバーアカウントからデータを取得するには、LINKED_ACCOUNTというパラメータにAccount Idを取得するように実装します。Lambdaコードは以下となります。返却されたレスポンスを整形して通知します。

def get_cost_report(account_id, start_date, end_date, filter_tags_condition):
    """
    指定された期間のコストレポートを取得
    Parameters:
    - account_id (str): AWSアカウントID
    - start_date (datetime.date): レポートの開始日
    - end_date (datetime.date): レポートの終了日
    - filter_tags_condition (list): タグによる絞り込み条件(Optional)
    Returns:
    - dict: コストと使用量の情報
    """

    query = {
        'TimePeriod': {
            'Start': start_date.strftime('%Y-%m-%d'),
            'End': end_date.strftime('%Y-%m-%d')
        },
        'Granularity': 'DAILY',
        'Metrics': ['BlendedCost'],
        'GroupBy': [
            {
                'Type': 'DIMENSION',
                'Key': 'SERVICE'
            }
        ]
    }

    if filter_tags_condition:
        query['Filter'] = {
            'And': [
                {
                    'Dimensions': {
                        'Key': 'LINKED_ACCOUNT',
                        'Values': [account_id]
                    }
                }
            ]
        }
        for filter_tag in filter_tags_condition:
            query['Filter']['And'].append({'Tags': filter_tag})
    else:
        query['Filter'] = {
            'Dimensions': {
                'Key': 'LINKED_ACCOUNT',
                'Values': [account_id]
            }
        }

    session  = get_sts_session()
    client   = session.client('ce', region_name='us-east-1')
    response = client.get_cost_and_usage(**query)
    return response

できたStep Functionを、「Amazon EventBridgeスケジューラ」などで定期実行すれば……。

screenshot_report

上のような形で、コスト通知を受信できるようになります。（今回は割愛しますが、実際には事前にSlack側でアプリ設定などが必要です）

まとめ

今回は、ITインフラ本部 SRE部のCCoE的な活動の一例としてAWS Organizationsを用いた共通処理の実装について、中でもコスト通知をご紹介しました。ほかのサービス運用に有用な情報通知も、同様の仕組みで提供していくことを進めています。AWSが提供する通知機能で十分な場合もありますが、通知内容をカスタマイズしつつ、処理の実装・実行は共通化すると、より効率よく事業や組織のニーズに応えられるのではないでしょうか。

現在、積極的な採用活動を行っています。CcoEまたはSRE的なアプローチで横断的にDMMサービスを改善していく仕事にご興味がある方、ぜひエントリーをご検討ください。