コネヒト開発者ブログ

コネヒト開発者ブログ

AWS Step Functionsに新たに14個追加された関数をいくつか使ってみた

こんにちは、インフラエンジニアのささしゅう(@sasashuuu)です。 本日は最近アップデートされ、新たに14個追加されたStep Functionsの組み込み関数について、いくつか活用事例を交えてご紹介したいと思います。

アップデートの概要

Step Functionsの組み込み関数アップデートに関するアナウンスは以下になります。 aws.amazon.com

また、組み込み関数のドキュメントは以下になりますが、日本語版のドキュメントにはまだアップデートされた関数の情報の記載が見当たらなかったため、英語版の方を貼っておきます。 docs.aws.amazon.com

配列操作、UUIDの作成、JSONオブジェクトの結合など計14個の組み込み関数のアップデートがありました。これらの組み込み関数はASL(Amazon States Language)というStep Functionsのリソースを定義するのに使用するJSONベースの構造化言語に直接追加されているため、そのまますぐにでもStep Functionsから利用することができます。

アップデートされた組み込み関数の種類や挙動に関してはクラスメソッド様が以下の記事で網羅的に取り上げられているので、こちらが参考になります。 dev.classmethod.jp

活用事例

ここからは、具体的な活用事例をご紹介します。 今回ご紹介するのは以下の5つです。

States.UUID

まずは1つめの States.UUID です。これは、v4 UUIDの乱数を返してくれる関数です。

活用事例としては、ワークフロー上で作成するAuroraクラスターとそれに紐づくインスタンスについて、既存リソースの識別子の命名をベースにしたいが、サフィックスとしてランダムな識別子を入れて被らないように命名したいというケースで活用しました。

次のようなイメージです。

  • 既に存在するリソースの命名(Auroraクラスターの識別子)
    • dev-hoge-aurora-cluster
  • あたらしく作りたいリソースの命名(Auroraクラスターの識別子)
    • dev-hoge-aurora-cluster-{ランダムな識別子}

ワークフロー実行時の入力です。

{
    "HogeDbClusterIdentifier": {
        "Identifier": "dev-hoge-aurora-cluster-{}"
    }
}

Pass ステートで States.UUID を使用して、生成した識別子を元の入力を上書きする形で更新します。

    "Pass": {
        "Type": "Pass",
        "Next": "Foo",
        "Parameters": {
            "Identifier.$": "States.Format($.HogeDbClusterIdentifier.Identifier,States.UUID())"
        },
        "ResultPath": "$.HogeDbClusterIdentifier"
    }

Auroraクラスターを作成します。(下記は RestoreDBClusterFromSnapshot を用いたスナップショットからの復元の例です。)

    "RestoreDBClusterFromSnapshot": {
        "Type": "Task",
        "Next": "Pass",
        "Parameters": {
            "DbClusterIdentifier.$": "$.HogeDbClusterIdentifier.Identifier",
            "Engine": "aurora",
            "SnapshotIdentifier": "hoge"
        },
        "Resource": "arn:aws:states:::aws-sdk:rds:restoreDBClusterFromSnapshot"
    }

結果、次のようなUUIDがサフィックスとしてついた識別子のクラスタが作成されます。(※インスタンス作成のステップはここでは割愛。)

dev-hoge-aurora-cluster-a7cae12b-3e92-4c7a-b2f5-07416d023dbc

States.StringSplit

続いては States.StringSplit です。これは、文字列を区切り文字で値の配列に変換してくれる関数です。 何かのパラメータを複数設定したい際などに便利で、活用事例としては、RDSのクラスター作成時のSGなどの指定で利用しました。

ワークフロー実行時の入力です。

{
    "SecurityGroups": "sg-01xxxxxx,sg-02xxxxxx"
}

続いてスナップショットからクラスターを復元する RestoreDBClusterFromSnapshot ステートの定義です。

    "RestoreDBClusterFromSnapshot": {
        "Type": "Task",
        "Parameters": {
          ...
          "VpcSecurityGroupIds.$": "States.StringSplit($.SecurityGroups, ',')",
                  ...
        },
        "Resource": "arn:aws:states:::aws-sdk:rds:restoreDBClusterFromSnapshot",
        "Next": "CreateDBInstance",
        "Catch": [
            {
                "ErrorEquals": [
                    "States.ALL"
                ],
                "Next": "NotifySlackFailureTheOthers"
            }
        ],
        "ResultPath": "$.Hoge"
    },

入力で渡していた SecurityGroupsStates.StringSplit の関数の第1引数に、区切り文字としてカンマを第2引数に与えることにより、API実行時のパラメータの指定を次のように展開してくれます。

    {
        ...
        "parameters": {
          ...
          "VpcSecurityGroupIds": [
                "sg-01xxxxxx",
                "sg-02xxxxxx"
            ],
          ...
        },
        ...
    }

States.MathAdd、States.ArrayLength、States.ArrayGetItem

最後にこの3つの関数の活用事例をまとめて紹介します。 ざっくり関数の性質を説明すると次のような内容です。

  • States.MathAdd
    • 引数に与えた2つの数値の合計値を返す。
  • States.ArrayLength
    • 引数に与えた配列の長さを返す。
  • States.ArrayGetItem
    • 引数に与えた配列とインデックスから対象の値を返す。

この3つの関数は一連のフローで組み合わせて次のようなケースで活用しました。

  1. ワークフローで実行するAPIのresponseのoutputが配列で返る
  2. States.ArrayLength で配列の長さを取得する
  3. 配列データをループ処理にかける
  4. States.ArrayGetItem で対象の配列とCounterとして用意していたパラメータを使用し、インデックスを指定して要素を取り出す
  5. 取り出した要素が処理の対象の要素かどうかを Choice ステートで判定する
  6. 対象の要素一致していなければCounterとして用意していたパラメータを States.MathAdd でインクリメントする、インクリメントが配列の長さに達している場合は処理をループ処理を終了する
  7. 再びループの先頭に戻る
  8. 繰り返し…

実際に簡略化して再現したものが次のようなものになります。

{
    "Comment": "A description of my state machine",
    "StartAt": "DescribeDBClusters",
    "States": {
        "DescribeDBClusters": {
            "Type": "Task",
            "Next": "Pass",
            "Parameters": {},
            "Resource": "arn:aws:states:::aws-sdk:rds:describeDBClusters",
            "ResultPath": "$.Output",
            "ResultSelector": {
                "Length.$": "States.ArrayLength($.DbClusters)",
                "DbClusters.$": "$.DbClusters"
            }
        },
        "Pass": {
            "Type": "Pass",
            "Next": "Choice",
            "Parameters": {
                "DbClustersLength.$": "States.MathAdd($.Output.Length, -1)",
                "DbCluster.$": "States.ArrayGetItem($.Output.DbClusters, $.Counter.Val)"
            },
            "ResultPath": "$.Tmp"
        },
        "Choice": {
            "Type": "Choice",
            "Choices": [
                {
                    "Variable": "$.Tmp.DbCluster.DbClusterIdentifier",
                    "StringMatches": "dev-hoge-aurora-*",
                    "Next": "Pass (2)"
                }
            ],
            "Default": "Pass (1)"
        },
        "Pass (1)": {
            "Type": "Pass",
            "Next": "Choice (1)",
            "ResultPath": "$.Counter",
            "Parameters": {
                "Val.$": "States.MathAdd($.Counter.Val, 1)"
            }
        },
        "Choice (1)": {
            "Type": "Choice",
            "Choices": [
                {
                    "Variable": "$.Tmp.DbClustersLength",
                    "NumericEqualsPath": "$.Counter.Val",
                    "Next": "Fail"
                }
            ],
            "Default": "Pass"
        },
        "Fail": {
            "Type": "Fail"
        },
        "Pass (2)": {
            "Type": "Pass",
            "End": true
        }
    }
}

DescribeDBClusters で全てのクラスターを取得し、先述したようなフローの処理を行なっています。

ワークフロー実行時の入力です。

{
    "Counter": {
      "Val": 0
    }
}

1つずつステートの処理を見ていきます。

最初の DescribeDBClusters ステートでは States.ArrayLength を使用し、 Output.Length のパスで取得したデータの長さを取得、Output.DbClusters のパスで取得したデータを丸ごとを取得し、元の入力と合わせて次のステートに引き継いでいます。

    "DescribeDBClusters": {
        "Type": "Task",
        "Next": "Pass",
        "Parameters": {},
        "Resource": "arn:aws:states:::aws-sdk:rds:describeDBClusters",
        "ResultPath": "$.Output",
        "ResultSelector": {
            "Length.$": "States.ArrayLength($.DbClusters)",
            "DbClusters.$": "$.DbClusters"
        }
    }

次の Pass ステートでは、States.MathAdd を使用し、Tmp.DbClustersLength のパスで本来の配列データから1を引いた数を取得、States.ArrayGetItem を使用し、Tmp.DbCluster のパスで対象のクラスター情報を取得し、次のステートに引き継いでいます。

    "Pass": {
        "Type": "Pass",
        "Next": "Choice",
        "Parameters": {
            "DbClustersLength.$": "States.MathAdd($.Output.Length, -1)",
            "DbCluster.$": "States.ArrayGetItem($.Output.DbClusters, $.Counter.Val)"
        },
        "ResultPath": "$.Tmp"
    }

さらに Choice ステートでは ループ上で絞り込んで取得している対象が dev-hoge-aurora-* というクラスターの識別子と一致しているかをチェックしています。

    "Choice": {
        "Type": "Choice",
        "Choices": [
            {
                "Variable": "$.Tmp.DbCluster.DbClusterIdentifier",
                "StringMatches": "dev-hoge-aurora-*",
                "Next": "Pass (2)"
            }
        ],
        "Default": "Pass (1)"
    }

一致していなかった際は Pass (1) へ移り、用意していた入力のCounterをインクリメントします。States.MathAdd を使い数値の1を追加しています。

    "Pass (1)": {
        "Type": "Pass",
        "Next": "Choice (1)",
        "ResultPath": "$.Counter",
        "Parameters": {
            "Val.$": "States.MathAdd($.Counter.Val, 1)"
        }
    }

もし、ここでインクリメントしていたCounterの数値が、取得していた配列データの数に達した場合は Choice (1) の判定により、処理が終了するようになっています。

    "Choice (1)": {
        "Type": "Choice",
        "Choices": [
            {
                "Variable": "$.Tmp.DbClustersLength",
                "NumericEqualsPath": "$.Counter.Val",
                "Next": "Fail"
            }
        ],
        "Default": "Pass"
    }

以上のように配列の操作系の組み込み関数も強化されているので組み合わせて柔軟に利用することができます。

余談ですが、ループ系の処理に関しては Map ステートという入力配列の要素ごとに一連のステップを実行してくれるものがあるのですが、ループ途中のBreakやそこからループ内の任意のoutputをもとの入力に統合するような実装などが難しいように感じ、今回は上記の組み込み関数を使用し、配列のループ操作を行いました。

おわりに

Step Functionsの組み込み関数が大幅にアップデートされ、ちょっとした計算処理や整形処理などがLambdaなどのリソースを使わなくてもワークフロー上で行えるようになり、非常に便利になりました。みなさんも機会があればぜひ積極的に活用することをおすすめします。

検索システムで再現率向上に取り組んだ話

こんにちは。エンジニアの永井(shnagai)です。

今回は、現在進めている検索システム内製化プロジェクトの中で、検索エンジニアとしてはほぼ未経験に近い自分が半年ほど試行錯誤した内容の一部を書き記していこうと思います。

※筆者の経験としては、Elasticsearch✕kibanaのログ基盤は複数構築経験はありで、Elasticsearch周りの設定への知識は0ではないレベル

この記事を見て、検索に詳しい方や自分もやってみたいという方がいたら是非お声がけいただけるとうれしいです。

内容は、ざっくり下記の構成になっています。

  • 作りながら身にしみた検索システムの奥深さ
  • 初回ABテストでは既存エンジンに惜敗。再現率向上を目指すためのチューニング
  • これから

作りながら身にしみた検索システムの奥深さ

プロジェクトの開始前に、そもそも検索システムを自社で作り運用していけるのかの当たりをつけるために、ママリのデータを使った検索システムのモック作りを開始しました。この時の自分は、暗に「1つの検索クエリに対していかに正確な検索結果を返すか」を解くべき課題と設定し、下記にあるように検索ワードに対して間違いの少ない検索システムを目指してモック作りを進めました。

社内向けのモックを作る際の最初の方針

  • 出来るだけ検索ノイズが少なくなるように
    • OpenSearchの match_phrase クエリを使って検索ワードの順序を厳格に判定
    • kuromojiはnormalモードを利用 ※searchで意図せぬトークン分割されるのを防ぐため
    • 家族ノートという別プロダクトを開発するときに作ったユーザ辞書をカスタム辞書として利用

※検索エンジンとしては、OpenSearchを採用しているのでクエリ等はOpenSearch(Elasticsearch7.10.2相当)のもの

その後、モックが出来上がり社内定性チェックを行い、そのFBを読み解く中で、下記のようなインサイトを得て少しずつ意識が変わってきました。

「検索クエリは検索者の検索意図を必ずしも表したものではない」

「検索クエリぴったりのものでなくても検索意図に合う結果であればよいパターンもある」

「0件ヒットの体験は検索システムとしてはかなり悪い」 ※コンテンツがそもそもなければもちろん許容

つまり、検索クエリは検索者の目的を必ずしも正しく反映したものではなく(自分的には目からウロコでした)、検索クエリからいかに意図を汲み取り次のアクションにつながる結果を返せるかが検索システムの役目ということをだんだんと理解し始めました。

そんな中、「検索システム」という良書をチームメンバが見つけ、検索システム内製化チームで輪読会をはじめました。この本は、めちゃくちゃ良書で今自分たちがぶつかっている課題等が見事に言語化されており毎度チームメンバとうなりつつ検索システムに対する理解を深めている最中です。

特に、「ルックアップベースの検索モデル」には課題があり、「クエリや検索行動」自体を理解する QueryUnderstandingが検索システムを作る上では欠かせないと解説されていて、めちゃくちゃうまく言語化されており自分が抱えていた課題感が腑に落ちたのを覚えています。 何回も読み直しており、めちゃくちゃオススメの良書です。

検索システム ― 実務者のための開発改善ガイドブック(電子書籍のみ) – 技術書出版と販売のラムダノート

初回ABテストでは既存エンジンに惜敗。再現率向上を目指すためのチューニング

「ルックアップベースの検索モデル」は、自分の中では出来るだけ間違いの少ない検索システムと捉えており、その方針で作った検索システムで最初のABテストに望みました。

結果、KPIに設定していた検索CTRの有意差判定で既存検索システムに負けてしまいました。

当初の検索システムは間違いを少なくするために適合率高めに設定していたのですが、検索ログから出した数値やユーザからのFBから再現率が低すぎる傾向が読み取れました。

適合率と再現率については、下記のelastic社のブログが詳しいのでこちらをご参照ください。

How to implement Japanese full-text search in Elasticsearch

www.elastic.co

さて、再現率向上のためのアプローチですが、ここではわかりやすい2つのチューニングについて説明していきます。

※一般的というよりはコネヒトの環境独自のチューニングの観点が大きいのでその点はご了承ください。

カスタム辞書のチューニング

ユーザからのお問い合わせベースで調査していると、地名を含めた検索で意図した検索結果になっていないことが見えてきました。

  • 地域名を入れた検索クエリで、検索結果が返ってこないケースがたまにある
    • 例)「厚木」では「厚木市」のドキュメントが当たらない

これは、別プロダクトで作ったカスタム辞書で市区町村が細かく定義されており、それをそのままKuromojiのカスタム辞書として利用していたことが原因でした。

わかりやすく、具体例で説明すると

厚木市の保育園 という文章をKuromojiで形態素解析すると

  • 【本来の形】 厚木/市/の/保育園 と分割され、厚木市 厚木 どちらでも検索にヒットする
  • 【ABテスト時点】 厚木市 というカスタム辞書が優先されるので、 厚木市/の/保育園 と分割されてしまう。結果、 厚木 という検索ワードでは厚木市の保育園 というドキュメントがヒットしない状況になっていました。

元のカスタム辞書は、BigQueryに独自の転置インデックスを登録するために作った辞書で、細かい単語を定義することに価値があったのですが、OpenSearchのKuromojiの辞書としてそのまま転用すると思わぬ落とし穴があったなという所感です。

地名系をカスタム辞書から一通り除外して、例のような検索クエリにドキュメントが返ることを確認しました。

Kuromojiのmodeをnormalからsearchに変える

日本語形態素解析エンジンとして、Kuromojiを使っているのですがモードを当初は normal にしていました。

詳細は、下記が詳しいのですが、複数の単語が組み合わさった単語をいい感じに分割してトークナイズしてくれるモードとのことで、再現率向上の観点から search モードを採用しました。

kuromoji_tokenizer | Elasticsearch Plugins and Integrations [7.10] | Elastic

www.elastic.co

上記2点のチューニングを行い、改めてABテストを実施したところ、再現率が向上とKPIにしているCTRで既存エンジンと有意差なしまで持っていくことが出来ました。

これから

今後、オートコンプリートや関連検索の提案等の複数検索機能も含めた検索システムを通して、よりママリの検索がユーザの悩みや課題解決につながる機能となっていくよう開発をしていこうと思います。

難易度が高くなるランキング周りの話やカスタム辞書のさらなるチューニング、シノニム(同義語)の整備、 QueryUnderstanding をチームで進めるためのログやモニタリングの整備等、検索めちゃくちゃやること多いなわくわくするなという思いをチームメンバはもっており、今後も走りながら進めていき、少しずつ事例も紹介していければと思っています。

最後にコネヒトでは検索システムを一緒に開発してくれるエンジニアを募集しています。

下記の募集以外にもポジションありますので、少しでも興味もたれた方は、是非気軽にオンラインでカジュアルにお話出来るとうれしいです。

https://hrmos.co/pages/connehito/jobs/00n

hrmos.co

コネヒトは PHP Conference 2022 に協賛します!

こんにちは!@TOC です。今回は弊社が協賛するイベントについて紹介します。

コネヒトは PHP Conference 2022 に協賛いたします

コネヒトではママリを始め、社内の多くのプロダクトが PHP で開発されております(その他、技術スタックを知りたい場合は弊社テックビジョンをご覧ください)

そんなコネヒトはこの度、 PHP Conference 2022 にシルバースポンサーとして協賛いたします!

イベント概要

今回はオフラインでの参加も可能ということで、盛り上がりそうですね!

台風が近づいておりますので、気をつけつつオンライン・オフラインで楽しみたいです🙌

また、最新情報は Twitter で告知されるので PHP Conference 公式 Twitter もチェックしてみてください。

@phpcon

最後に

会場では弊社デザイナーが作ってくれた素敵なジョブボードも掲載いたします🙆‍♂️

みんなで楽しんでいきましょ〜!

コネヒトでは PHPer を積極採用中です!

hrmos.co

AWS SESでハードバウンスのようなメールがソフトバウンス扱いで届いた場合のしくみと対処について

こんにちは、インフラエンジニアのささしゅう(@sasashuuu)です。 本日はAWS SESにおけるバウンスメール周りのお話をしようと思います。 タイトルにもあるように、ハードバウンスのようなメールがソフトバウンス扱いで届き、気になってサポートへ問い合わせた際のお話をご紹介します。

バウンスメールとは

そもそもバウンスメールとはなんらかの原因により配信できなかったメールのことで、その種類にはソフトバウンスとハードバウンスがあります。

違いは以下のような内容です。

  • ソフトバウンス
    • 一時的な原因による配信失敗のメール(送信先のメールボックスがいっぱいだったなど)
  • ハードバウンス
    • 恒久的な原因による配信失敗のメール(そもそも宛先のメールアドレスが存在しないなど)

詳細な内容は過去のブログでも取り上げておりますので、よろしければご覧ください。

tech.connehito.com

届いたメールの内容

今回届いたバウンスメールの一部は以下のような内容です。

{
    "notificationType": "Bounce",
    "bounce": {
        "feedbackId": "xxxx-xxx-xxx-xxx-xxx-xxx-xxxxxx",
        "bounceType": "Transient",
        "bounceSubType": "General",
        "bouncedRecipients": [
            {
                "emailAddress": "xxxxxxxxxxxx",
                "action": "failed",
                "status": "5.1.1",
                "diagnosticCode": "smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found"
            },
            ...

SESによってハンドリングされたバウンスメールは上記のようなJSONオブジェクトの形で配信されるのですが、いくつか項目をピックアップして見ていきましょう。(※詳細は公式ドキュメントを参照。)

  • notificationType

    • 通知のタイプです。
    • Bounceが入っているのでバウンスメール扱いとなります。
  • bounceType

    • SESによって決定されるバウンスタイプです。
    • Transientがソフトバウンスになります。

      ソフトバウンスであるかどうかを判断するには、SNS 通知の内容を確認します。bounceType  が Transient  の場合はソフトバウンスです。ソフトバウンスのタイプを確認するには、bounceSubType の値を確認します。

      aws.amazon.com

  • diagnosticCode

    • DSNのDiagnostic-Codeフィールドの値です。
    • 配信が不可であった場合に返ってくる応答メッセージかな(?)と解釈しております。
    • ちなみにsmtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not foundとなっています。いかにも宛先などが見つからなかったようなメッセージですね。
    • なお、SESのデベロッパーズガイドのメールボックスシミュレーターのシュミレートシナリオや、バウンス応答アクションのテンプレート説明などでは、不明なユーザーやメールボックスが見つからなかったことなどを示唆するメッセージが見て取れます。

      バウンス – 受取人のEメールプロバイダー は、SMTP 550 5.1.1 レスポンスコード (「不明な ユーザー」) レスポンスコードで E メールを拒否 します。

      https://docs.aws.amazon.com/ja_jp/ses/latest/dg/ses-dg.pdf

      Mailbox Does Not Exist - SMTP 応答コード = 550、SMTP ステータスコード = 5.1.1

      docs.aws.amazon.com

詳細は後述しますが、今回はこの smtp;550 5.1.1 RESOLVER.ADR.RecipNotFound; not found のレスポンスメッセージがSES側で未知のものであったことがソフトバウンス認定されてしまっていた原因でした。

問い合わせと回答

これまでの内容を踏まえ、以下2点について内容をまとめサポートへ問い合わせをしました。

  • なぜこのようなハードバウンスのような内容のメールがソフトバウンス扱いで届くのか。
  • アカウントレベルのサプレッションリストの使用 のように、任意のソフトバウンスメールのメールついて2回目以降の送信が行われないような機能、または良い方法はあるのか。

得られた回答の要点をざっくりとご紹介します。

まず1点目の「なぜこのようなハードバウンスのような内容のメールがソフトバウンス扱いで届くのか」については以下の内容です。

  • SES は受信MTAからのレスポンスからハードバウンスが発生したかどうかを判定する。
  • しかしながら受信MTAによって異なるレスポンスメッセージを利用するため、SES が把握していないレスポンスメッセージが受信MTAから返却される場合がある。
  • その場合、顧客のバウンス率の評価に悪影響を与えないようにSESではハードバウンスではなくソフトバウンスが発生したものとして扱う。

このようにSESが把握していないレスポンスメッセージに関しては意図的にソフトバウンス扱いとして対処しているとのことでした。

また、本件に関するレスポンスメッセージに関しては問い合わせ後、ハードバウンスと判定されるような修正を反映してくださったようで、今後本件のような事象(ハードバウンスのような内容がソフトバウンスで届く件)が発生した場合は同じようにフィードバックが欲しいとのことでした。(バウンス判定の質の向上のために使用したいとのことでした)

そして2点目の「アカウントレベルのサプレッションリストの使用 のように、任意のソフトバウンスメールのメールついて2回目以降の送信が行われないような機能、または良い方法があるか」については以下の内容です。

  • SES のサービスのみでは実現が難しいため以下のような対応が案としてあげられる。
  • 対象のアドレスについて、手動でサプレッションリストに登録する。
  • Lambda関数にて特定の条件を満たした場合に対象のアドレスをサプレッションリストに登録するコードを実装し、SESのSNS通知と連携する。

問い合わせ時点ではSESの機能で要件を満たすものはないそうで、手動でのオペレーションや他のAWSサービスを組み併せて対応する必要があるみたいでした。

まとめ

最後に本記事の要点を簡単にまとめておきます。 AWS SESで把握していないMTAからのレスポンスメッセージはバウンスレートに影響しないようにハードバウンスであってもソフトバウンスとして扱われます。もしこのような状況に遭遇した場合はサポートへフィードバックを送り、解消を図るのが良いと思います。また、そうでなくとも任意のソフトバウンスメールを2回目以降に送らせないようにするには手動でサプレッションリストに登録する、もしくはSES・Lambda・SNSなどのサービスを組み合わせて独自のシステムを構築するのが良いと思います。 もし同じような現象に遭遇し、お困りの方がいれば本記事の内容をご活用いただければと思います。

AWS Step FunctionsのRestoreDBClusterFromSnapshotだけではクラスタに紐づくインスタンスは作成されない

こんにちは、インフラエンジニアのささしゅう(@sasashuuu)です。

本日は、Step Functionsを用いてデータの同期更新システムを構築した際に少しだけハマったポイントについてご紹介です。

Step Functionsとは

Step FunctionsとはAWSの各種サービスを組み合わせた一連の処理の自動化などがローコードで行えるAWSのサービスです。

aws.amazon.com

弊社でも過去にいくつかStep Functionsを使用した導入事例を記事にしているので、もしご興味があればご覧ください。いくつかピックアップしておきます。

tech.connehito.com tech.connehito.com tech.connehito.com

やりたかったこと

前述したように、Step Functionsのワークフローを用いてデータの同期更新をするシステムを構築していました。その過程で同期元のRDSのスナップショットからAuroraクラスタおよびそれに紐づくインスタンスを復元しようとワークフローを組んでいました。

以下はそのフローの一部分です。

ここでは、DescribeDBClusterSnapshotsのステートで処理を実行し、取得したスナップショットの識別子を元にRestoreDBClusterFromSnapshotのステートでクラスターおよびクラスタに紐づくインスタンスを復元しようとしていました。

しかし、待てど暮らせどインスタンスは現れてくれません…。

以前検証のためにコンソールからスナップショットを使用して、クラスターの復元をおこなったことがありました。その際は対象のスナップショットの画面から「アクション」>「スナップショットを復元」>「DBクラスターを復元」で「えいっ、ポチッ」とやればインスタンスも丸っと綺麗に復元できたんだけどな…。(※以下、オペレーション時のイメージのキャプチャ)

今回Step Functions上で同じようなことを再現したかったのですが、どうもうまくいきません。

何が起こっていたか

結論、叩くAPIが足りていませんでした。

Step Functions上でRDSのスナップショットからの復元という要件を満たすには、RestoreDBClusterFromSnapshotとはまた別のステートでインスタンス作成を行う処理が必要でした。

前述したAWSコンソールからの実行時の例では「DBクラスターを復元」というsubmitボタンを押下した後、裏でよしなにクラスターの作成とインスタンスの作成のAPIの実行が両方走っていたのです。コンソールから「DBクラスターを復元」を実行した際に実行されるAPIは次の通りです。

この辺りは実行後、Cloud Trailのログなどを見るとよくわかります。

やらなければいけなかったこと

下記のようにワークフローを修正すれば良いです。

CreateDBInstanceのステートを追加しました。

これで晴れて、クラスターおよびインスタンスを含めスナップショットからの復元を行うことができます。

補足

上記の挙動は公式ドキュメントにも明記されていました。

コンソールを使用して DB クラスターを復元する場合、Amazon RDS は自動的に使用する DB クラスターのプライマリインスタンス (ライター) を作成します。RDS API を使用して DB クラスターを復元する場合は、DB クラスターのプライマリインスタンスを明示的に作成する必要があります。

docs.aws.amazon.com

現時点では、コンソールを使用したオペレーション時のみプライマリインスタンスを作成する挙動となっているようです。

今回はStep Functionsを用いたスナップショットからのRDS復元時に少しだけハマったポイントについてご紹介しました。また、ハマりポイントの小ネタなどがあれば更新しようと思います

ニアリアルタイムで同期される検索基盤 ~パイプライン構築編~

皆さん,こんにちは!MLエンジニアの柏木(@asteriam)です.

今回は前回のエントリーに続いてその後編,パイプライン構築の話になります. tech.connehito.com

はじめに

再掲になりますが,我々は以下の構成で今回の検索基盤を構築しています.

  • 検索エンジン:Amazon OpenSearch Service
  • データベース:Amazon Aurora
  • データ同期(ETL):AWS Glue
  • ワークフロー・パイプライン:AWS Step Functions・Lambda・EventBridge

後編は,検索エンジンに定期的に安定してデータを同期するために構築しているワークフロー・パイプラインに関する内容になります(下図の全量データ同期パイプラインの部分).

検索基盤全体のアーキテクチャー概略図

もう少し具体的には,OpenSearchのindexの管理方法について説明した後に,パイプラインの話とパイプラインのコード管理の方法の順番で紹介していきたいと思います.


目次


OpenSearchのindex管理

我々は2つのindexを用意し,その上段にaliasを置く方法でOpenSearchのindexを管理しています.aliasを置く理由としては,以下の理由が一番大きいです.

  • アプリケーション側で接続先を毎回変更する必要がない

また,接続先の変更ミスなどが発生すると適切なドキュメントにアクセスできなくなるといったこともあり,アプリケーション側からは常に同じ接続先にすることで上記問題を気にせずにリクエストを検索エンジンに投げることができます.

OpenSearch内でのindexの構成

indexに入るデータはGlueから同期されるようになっており,後述するパイプラインを用いてデータが安全に入る仕組みを構築しています.

一方で,我々はOpenSearchのReindex APIを使ってindexの作り替えをしているのではなく,全量データを数日(サービス仕様のためボカしています)に1回洗い替え作業を実施し,indexを一度削除してから新規で作り替えを行っています.そのタイミングで,裏側でaliasを切り替えている状況になります.

なぜindexの作り替えを毎回実施しているのか

数日に1回全量データの洗い替え作業を実施しており,このタイミングでindexの作り替えを行っています.洗い替え作業を行う理由としては,

  • データの漏れや欠損が発生していた場合にそれらを洗い替え時に拾うことができるため

この処理はデータの取りこぼしがあった時の保険的な役割が大きいです.そのため,Reindex APIは既存のindexのコピーになるので,それだけだと不十分で毎回indexを作り替えることをしています.

indexの切り替えフローの紹介

洗い替え時のindexの切り替えフローを紹介しようと思います.流れとしては下図のようになっています.

洗い替え時のindexの切り替えフロー

今,indexAとindexBの2つがあるとして,aliasはindexBを向いている(alias→indexB)とします.差分データの更新がindexBで続いており,indexAはスタンバイ状態になります.

まず,indexAの削除をした後,AWS Glueによる全量データの同期をindexAに対して行います.これによりindexAに最新のデータが入った状態になります.その後aliasの向き先をindexBからindexAに変更します(alias→indexA).これで取りこぼしがあった場合でも,補完することができ,データをindex化することができます.あとは次回洗い替え時にAとBが入れ替わった形でまた処理が実行されます(indexAとBで交互にループしている状態).

これらの処理をStep Functionsのパイプライン上で実現して日々実行されています.

ワークフローとパイプラインの役割

では,実際にパイプラインの処理はどんな感じになっているかを紹介していきます.

今回,ワークフローとパイプラインというように分けていますが,それぞれの役割をまずは説明します.ちなみにこれらはどちらもStep Functionsを用いて構築しています.

  • ワークフロー
    • 2つのindexに対応したパイプラインがあり,そのどちらを使用するかを制御する
    • EventBridgeによるスケジュール実行の対象となり動作する

ワークフローの構成図

  • パイプライン
    • 上図にあるStep Functionsの実体で,辞書更新とデータ同期の処理を行う

全量データ同期のパイプライン構成図

なぜワークフローとパイプラインで分けたのか?

なぜこの2つに分けたのかを説明していくと,問題点と解決策は以下のようになりました.

  • 問題点:数日に1回のスケジュール設定をEventBridgeで行えなかった
    • 開発当初は2つindexに対して用意したパイプラインに対して,それぞれスケジュールを割り当てて実行しようとしていたのですが,数日に1回のスケジュール設定を上手くそれぞれのindexのパイプラインが交互に実行するのができないことがわかった
      • 月によって31日がなかったりなどの影響があり
  • 解決策:それぞれのパイプラインを管理するワークフロー的な役割を用意
    • 2つのパイプラインを制御する役割として,上段にワークフロー的な役割をするStep Functionsを用意することで,上手くこの問題を回避した
    • EventBridgeによるスケジュール設定をこのワークフローに割り当て,現在どのindexに対してaliasが接続しているかをチェックすることで,その後にどちらのパイプラインを流せば良いかを判断している存在とした

この結果,管理するEventBridgeも1つになったのと,ワークフローを確認することでどちらのパイプラインに処理が流れたかを一目で確認することができるようになりました.

全量データ同期パイプラインの詳細

次にパイプラインの詳細を見ていこうと思います.このパイプラインの中には大きく2つの処理パートがあります.

  • 辞書更新パート
  • データ同期パート

全量データ同期のパイプライン構成図

辞書更新への対応

パイプラインの最初の処理に辞書更新の有無を判断しているステップがあります.これはS3に置いてある辞書ファイルが直近で更新があったかをチェックし,更新があればこの辞書更新のパートに処理が進んでいきます.無ければこの処理はスキップされます.

辞書更新のフローを別に切り出すことも可能でしたが,少ない数のパイプラインで管理したいのと,運用を考えた場合に,意識せず上段のワークフローを再実行することで辞書更新も取り込んだ形でindexの更新が行えるのがベストだと思ったのもあり,メインのパイプラインの中に組み込んだ形を取っています.

辞書更新のパートでは,「ユーザー辞書」や「同義語辞書」の更新を行える処理になっています.これらの辞書を更新するためには,OpenSearchの更新を行う必要があり,更新された辞書情報はindexの作り替え時に適用されることになります.

OpenSearchの更新をするためには,パッケージの更新とその関連付けの処理を行う必要があり,こちらの公式ドキュメントが一部参考になるかと思います.

上記処理はStep Functionsのアクションに登録されているので,それらを用いて処理を組み立てています.

OpenSearchのindexの切り替え方法

先述した「indexの切り替えフローの紹介」の章で説明した内容をデータ同期パートでStep Functionsのフローに落とし込んでいます.

OpenSearchへはLambdaを用いてAPIを叩いてindexのdeleteやaliasの切り替えを行っています.

ここでのindexの切り替えステップは,検索システム-実務者のための開発改善ガイドブックの「8.5.1 インデクサの更新」の章でも書かれているように,Blue/Greenデプロイの形になっていて,新しいindexへのデータ投入が完了した後に,aliasの向き先を古いindexから新しいものに変更することで安全にデプロイをしています.その際に,新しいindexへの差分データ同期のパイプラインを有効化,古いindexへの同期処理は無効化することでパイプラインの完全な切り替えが完了します.

データパイプラインのコード管理

最後に,これらの複数のパイプラインをコード管理する方法ですが,AWS SAMによるパイプラインのコード管理を行っています.

AWS SAMとは,AWS Serverless Application Model (AWS SAM) といい,サーバレスなAWSリソースを管理するツールになります.サーバレスに特化したCloudFormationを拡張したものと言え,今回使用したLambda・Glue・Step Functionsなどのリソースは全てコード管理することができます.

ディレクトリ構成は以下のような感じになります.

.
├── README.md
└── sam
    ├── env
    │   ├── dev
    │   │   ├── samconfig.toml
    │   │   └── template.yaml
    │   └── prd
    │       ├── samconfig.toml
    │       └── template.yaml
    ├── functions/(Lambdaの定義)
    ├── glue
    │   ├── dev/(GlueJobの定義)
    │   └── prd/(GlueJobの定義)
    └── statemachine/(StepFunctionsの定義)
  • Step FunctionsとLambdaは共通化し,Glue Jobはdev/prdで個別にスクリプトを用意し,環境差分はtemplate.yamlの定数で定義
  • 共通変数はtemplate.yamlのParametersに記載

コード管理することで,いくつか利点があります.

  • 設定した内容を別環境に簡単に適用することができる
  • コードレビューが可能になり,設定ミスや漏れなどに気づきやすい
  • 環境依存部分をパラメータ化することで,テンプレートファイルで簡単に管理・切り替えが可能

ABテストを実施する際など,同一の環境をもう1セット用意する必要がある場合でもコード管理しておくこと,コマンド一発で環境を用意できるので,コード管理の恩恵を多分に受けています.

細かい設定ファイルの中身についてはここでは記載しないですが,今度登壇させて頂くJAWS DAYS 2022(2022-10-08 (土))でもう少し説明しようと思っていますので,気になる方はこちらのイベントを確認して貰えると嬉しいです!(資料は公開予定ですので,そちらでも可能です)

おわりに

今回構築したパイプラインは再実行を行いたい場合でも,input情報の設定をすること無く実施できるので,属人性もなく,indexの向き先なども気にせずに実行できるので運用がかなり楽になった仕組みだと感じています.

また,パイプラインもコード管理しておくことでチーム内の他のメンバーが環境構築する際にも簡単に実行できたり,スクラップ&ビルドも容易だったりして整理しておくと色々と恩恵があるなと感じています.

今後もより安心安全で信頼性が高いパイプライン構築のために,改善できる部分はよりブラッシュアップしていこうと思っています.

再掲になりますが,JAWS DAYS 2022でも今回のテックブログの内容を紹介する予定になっていますので,是非興味がある方はイベント登録(無料)して頂いて見て貰えると嬉しいです.

  • 登壇時間:2022-10-08(土)14:20~15:00
  • タイトル:AWSのマネージドサービスで実現するニアリアルタイムな検索基盤

jawsdays2022.jaws-ug.jp

最後に,コネヒトではプロダクトを成長させたいMLエンジニアを募集しています!!(切実に募集しています!)
もっと話を聞いてみたい方や,少しでも興味を持たれた方は,ぜひ一度カジュアルにお話させてもらえると嬉しいです.(僕宛@asteriamにTwitterDM経由でご連絡いただいてもOKです!)

www.wantedly.com

GitHub Actions & ecspresso を用いたデプロイフローの改善

こんにちは。サーバーサイドエンジニアの TOC です。

本日はコネヒト株式会社で取り組んでいる Super X という活動の一環である「デプロイフロー改善」の取り組みを紹介しようと思います。

本記事で紹介した改善以外にも、デプロイフロー改善チームで取り組んだことは別エントリでお届けする予定です✨


目次


はじめに

そもそも Super X って何?と思われるかと思うので、取り組みのご紹介をしようと思います!

Super X はエンジニア組織として追っている目標のプロジェクト名で、開発組織の中で課題となってる負債の解消などに取り組んでいく活動です!

今回私は 「デプロイフロー改善」を上期のテーマとして選び、活動を行ってまいりました。

抱えていたデプロイフローでの課題

※以下、「開発環境」は一般的に言うステージング環境を指しています。

弊社では過去に ecs-deploy を用いたデプロイを ecspresso に変更する取り組みがありました。(ref. GitHub Actions & ecspressoによるデプロイフロー構築

上記取り組みで ecspresso 導入がされたものの、以下の課題が残っていました。

  1. 開発環境と本番環境で別々の Docker イメージが利用されている
  2. ロールバックの方法が確立してない

1.については開発環境で検証した Docker イメージを本番環境でも利用した方が安心であるのと、本番環境デプロイ時に再ビルドが発生するので余計な時間がかかっているのを解消したいと思っていました。

2.については、ecspresso を使えば簡単にロールバックできるものの、その運用方法が社内で確立していなかったので、この際に他リポジトリに展開できるまで運用方法を確立しようという話になりました。

各課題の解決方法

開発環境で検証した Docker イメージを本番環境のデプロイで利用する

前提として、ecspresso を用いたデプロイフローはざっくり下記のようになっております。

1. 最新コードのチェックアウト
2. イメージをビルドし、ECR へプッシュ
3. ecspresso を利用して ECS タスク定義の更新・デプロイ

今回の改善では開発環境で上記のデプロイフローを行い、本番環境では下記のデプロイフローを行うことを目指します。

1. 最新コードのチェックアウト
2. ecspresso を利用して、開発環境で作成したイメージを参照するように ECS タスク定義の更新・デプロイ

このとき Docker イメージにつけるタグ名としては以下を満たす必要があると考えました。

  • 開発環境デプロイ時に利用できるものであること
  • タグ名が :latest などに固定されないこと(ecspresso のロールバックを考慮する)

上記2点を考慮すると、コミットハッシュをタグにするのがいいのではないか、という話になりました。

コミットハッシュならば、Github Actions 内で github.sha で取得ができます。 取得したコミットハッシュをイメージのタグ名として、イメージのビルド・ECR へのプッシュを行い、ecspresso でそのイメージを利用する形にすれば、開発環境で検証したイメージを本番環境デプロイ時に流用できる設計となりました。

デプロイフローのイメージ図

これにより、本番デプロイの actions は以下のようになり、だいぶシンプルになりました(一部抜粋)。

on:
  push:
    tags:
      - '*'

env:
  AWS_ROLE_ARN: hogehoge

permissions:
  id-token: write
  contents: read
  actions: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      # 通知など前処理
      - name: Checkout
        uses: actions/checkout@v2
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          role-to-assume: ${{ env.AWS_ROLE_ARN }}
          aws-region: aws-region
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1
      - uses: kayac/ecspresso@v1
        with:
          version: latest
      - name: Deploy to Amazon ECS
        env:
          IMAGE_TAG: ${{ github.sha }}
        run: |
          ecspresso deploy --config .ecspresso/production/config.yaml
      # 後続処理

ロールバック方法の確立

デプロイが完了し、タスクは正常に起動したもののアプリケーションの動作に問題が発生したので戻したい場合には、ecspresso rollback コマンドを使用します。

ドキュメントによると、ロールバックをすると下記動作が走ります。

  1. 現在サービスに設定されているタスク定義の「ひとつ前」のリビジョンを見つける
  2. ひとつ前のリビジョンのタスク定義をサービスに設定する

ref. ecspresso advent calendar 2020 day 6 - rollback

なので理論上、有効なリビジョンのタスク定義がある場合は無限にロールバック可能です。

このとき、--deregister-task-definition オプションをつけるとロールバックを行ったタスク定義を登録解除 します。 つまり、1回異常が起きたタスク定義はもう使わない、という思想のようで、ecspresso 作者の方も特別な事情がない場合はこのオプションをつけることをおすすめしています。

このオプションをつけることで、無限に戻れはするが、戻った際に過去ロールバックをした定義は使われない状態が作れます。 なのでロールバック時はオプションを指定したコマンドを実行するように修正しました。

ecspresso rollback --deregister-task-definition --config .ecspresso/production/config.yaml

ちなみに ecspresso Roadmap to v2 を見ると、このオプションがデフォルトで true になるようなので、いずれオプション指定しなくても良くなりそうですね🙌

その他工夫した点

デプロイジョブの並列化

場合によっては複数の ECS 環境にデプロイを行いたい場合があるかもしれません。その際にジョブを直列で書くと、1つの環境でデプロイが終わらないと次のデプロイが始まりません。

そんな時はジョブを並列化するとデプロイ時間が短縮されます。

deploy_1:
  needs: build
  runs-on: ubuntu-latest
  steps:
    # デプロイ
deploy_2:
  needs: build
  runs-on: ubuntu-latest
  steps:
    # デプロイ
deploy_3:
  needs: build
  runs-on: ubuntu-latest
  steps:
    # デプロイ

上記のように needs: build でビルド作業が終わったら各ジョブが走るようにします。

デプロイ並列化

actions の詳細を見ても上図のように並列実行できていることがわかります。

並列化したジョブの結果を取得する workflow-conclusion-action の利用

デプロイをする actions では最後にデプロイ結果を通知するジョブを用意しています。デプロイのジョブを並列化した場合、どれか1つでもジョブが失敗したら通知としては失敗と通知してほしい気持ちになります。

通常ジョブの成功/失敗は job.status で取得できますが、これは1つのジョブの成否になるので、ジョブが分かれた場合、前段のジョブが成功したのか、失敗したのかはわかりません。

そんな時は workflow-conclusion-action が便利です。

notify_end:
  needs: [ deploy_1, deploy_2, deploy_3 ]
  runs-on: ubuntu-latest
  if: always()
  steps:
    - uses: technote-space/workflow-conclusion-action@v2
    - name: Notify slack of deployment result
      uses: 8398a7/action-slack@v3
      with:
        status: ${{ env.WORKFLOW_CONCLUSION }}
        fields: repo,commit,ref,workflow,message
        author_name: ${{ github.actor }}
        text: |
          Deployment has ${{
            (env.WORKFLOW_CONCLUSION == 'success' && 'succeeded') ||
            (env.WORKFLOW_CONCLUSION == 'failure' && 'failed') ||
            'cancelled'
          }} to hogehoge.
      env:
        SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

このように各デプロイ全て終わった後に実行し、結果を env.WORKFLOW_CONCLUSION で取得すると、どれか一つでもデプロイが失敗した場合は失敗の通知をしてくれます。

まとめ

今回は ecspresso を用いたデプロイの更なる改善方法をご紹介しました。

仕組みが整っていると、普段あまり意識しなくても流れに乗ってしまえばできてしまうデプロイですが、これを機に CI 周りの理解だけでなく、ECR、ECS などインフラ側の理解も進んだので、非常に良い機会でした。

今回ご紹介した方法が、日頃の開発の何か参考になれば幸いです。

PR

コネヒト株式会社では絶賛エンジニア募集しております!

今回のような活動に興味を持った方、ぜひ一度お話させてもらえるとうれしいです。

hrmos.co

参考

ecspresso handbook