Ubieにおけるプラットフォームエンジニアリングの取り組み2023

はじめにヘルステックスタートアップのUbieに転職してから3ヶ月が経過したので、転職のきっかけや実際に入社して感じたことなどを書き連ねました。いわゆる入社エントリというやつです。転職の経緯前職ではDMMでSREをやっていました。特定のサービスに限定した活動ではなく、組織全体に関わるチームに属し、様々な部門に対してクラウドマイグレーションやインフラの改良、SRE文化の普及といった活動をしていました。DMMは50以上の多種多様なサービスを運営しており、新規事業の立ち上げ時にインフラ設計を行ったり、既存のレガシーインフラを改善するなど、多岐にわたる経験ができたことは大変有意義でした。一方で私が所属していた部署では「このサービスのこの部分を改善してほしい」といったスポットでの関わりが多く、もう少し長い目線でプロダクトや基盤を育てていきたいという気持ちがありました。そんな折に登録していた転職ドラフト経由でUbieから声がかかり、何度かの面接を経て今年の6月に入社することとなりました。「なぜUbieを選んだのか？」という質問をよく受けます。一番の理由は、「今後数年でN倍の成長が見込まれる、勢いのある企業で働きたかった」からです。成長企業は多くの資本や情報が集まり、環境の変化も早いです。強いエンジニアがUbieに集まってくる様子をTwitterで見てきたことも、この決断に大いに影響しました。そういった環境で挑戦することが、自分自身にとって新鮮で興味深いと感じました。また、その他の理由としては、ストックオプションを含む報酬体系の魅力や、オフィスを訪れた際の良い雰囲気なども挙げられます。note.com自分のエンジニアとしてのキャリアはまだ浅い方で、不安も少なからずありました。しかし、「情熱プログラマー」で紹介されていた"Be the worst"（一番下手くそでいよう）という言葉を思い出し、思い切って飛び込んでみることにしました。やっていること弊社のプロダクトの1つである症状検索エンジン「ユビー」は月間700万人以上の方に利用されています。サービスの成長に伴いスケーラビリティ、信頼性、開発効率といった点での課題が生じており、私の所属するチームでは基盤開発やSREといった切り口での解決を目指しています。ubie.appPlatform Engineeringというワードが近年注目されています。私の直近の仕事ではそこで定義されているような「製品チームによる顧客価値の提供を促進する」といった仕組みづくりに取り組んでいます。例えば、簡単に組織のポリシーやベストプラクティスに沿った方法でのサービス構築を可能とするService Templatingツールの開発や、社内のマイクロサービスのステータスやオーナーシップを可視化し、一元的に提供するInternal Developer Potalの構築などがその一例です。Platform Engineeringという概念はまだ提唱されてから日も浅いため、今後もさまざまなプラクティスやツールが登場すると予想されます。そういったトレンドを追いかけつつ、現在のUbieのプラットフォームにとって最適なHowを考えるのが難しいところであり、楽しいところでもあります。業務のアサインに関して少し補足しておくと、私の所属するUbie Product Platformはホラクラシーという組織体系を採用しており、明文化されたロールにWill/Can/Mustを考慮しつつ人が紐づくというのを特徴の1つとしています。ほとんどの社員は複数のロールを兼任するため、自分も先ほどのPlatformに関するロールの他に、認証基盤開発やSREといったロールを兼任しています。そちらのロールでは認証基盤とのやりとりに使うSDKの開発や、Ubieのインフラが乗っているKubernetesの運用などを行っています。note.com実際に入ってみてどうかカルチャーカルチャー構築、浸透に対する熱量が高い、というのが入ってすぐ抱いた印象でした。公開されているカルチャーガイドを眺めると分かる通り、ここまでボリュームのあるカルチャーを定義している会社は多くないのではないでしょうか。社内でもこのガイドにある用語（Giant Leap: 通称ジャイリーなど）が普段から多く飛び交い、社内の定例会議などでもよく話題に上がります。私のような新入社員はこのカルチャーを理解するだけでも結構大変だったりするのですが、それを支えるのが入社後のカルチャーオンボです。そこではカルチャーメンターが付き、共に前職のカルチャーとの差分を埋めるワークを一定期間行います。その中で今までの仕事のやり方とUbieで求められる行動指針との間で乖離があれば、どのようにそれを埋めていくかのアクションが積まれ、日々の業務の中でそれに取り組んでいきます。そのようにして新入社員が短期間で既存のUbie社員と足並みを揃え、同じ方向を向けるような仕組みが整えられています。評価制度がないUbie Product Platformでは報酬に紐づく等級・評価制度を持っていません。note.comこれは結構気に入っているポイントです。評価がないので、ある期間は上司がやたらと忙しくて捕まらないとか、評価されるために色々政治が必要とかもありません。ベテランエンジニアがメンバーの評価といったピープルマネジメントに忙殺されることもないので、プロダクト価値を上げる活動に専念できます（念のために言っておくと、これは一般的な話で前職の話ではありません）。また基盤よりの仕事をして感じることとして、サービス継続のためにはマイグレーションやバージョンアップといった高く評価されづらいものの重要なことがたくさんある、ということです。評価がないと、余計なことを気にせず事業にとって重要なことに集中できます。終わりに色々と良いことを書いてきましたが、技術的・組織的な課題もたくさんあります。絶賛採用中なので興味のある方はぜひお話ししましょう！recruit.ubie.life

Ubieに入社していました

Pub/Subに届いたメッセージをトリガーにしてCloud Functionsを呼び出す方法についてTerraformを使うケースを想定するTL;DRPub/SubトリガーでCloud Functionを呼び出す場合回避方法権限まわりおわりにTL;DRDead Letter Queue（DLQ）を使いたい場合はサブスクリプションで設定するサブスクリプションはCloud Functions側でイベントトリガーとなるトピックを設定すると自動で生成されるそのためTerraformではresourceとして現れず、（importしない限り）設定できないサブスクリプションからHTTPトリガーでCloud Functionsを呼び出す形にするとこの問題を回避できるHTTPトリガーで認証付きのCloud Functions gen2を呼び出す場合は、呼び出し側にroles/run.invokerのロールが必要gen1で必要となるroles/cloudfunctions.invokerと異なるPub/SubトリガーでCloud Functionを呼び出す場合Pub/SubとCloud Functionsを接続する際はPub/Subトリガーを使って呼び出すのがよくあるパターンである。次のようなTerraformをapplyすると、Pub/SubトピックとCloud Functionに加え、自動でサブスクリプションとEventarcのトリガーが作成される。resource "google_pubsub_topic" "tftest" {  name = "tftest-topic"}resource "google_cloudfunctions2_function" "image_transform" {  name        = "image-copy-function-2"  description = "Copies image from source bucket to destination bucket"  location    = "asia-northeast1"  build_config {    runtime     = "nodejs16"    entry_point = "handleImageUpload"    source {      storage_source {        bucket = google_storage_bucket.image_transform_function.name        object = google_storage_bucket_object.function_source.name      }    }  }  service_config {    max_instance_count               = 3    min_instance_count               = 1    available_memory                 = "4Gi"    timeout_seconds                  = 60    max_instance_request_concurrency = 80    available_cpu                    = "4"    environment_variables = {      DESTINATION_BUCKET = google_storage_bucket.tftest.name    }    ingress_settings               = "ALLOW_INTERNAL_ONLY"    all_traffic_on_latest_revision = true    service_account_email          = google_service_account.image_transform_function.email  }  event_trigger {    event_type     = "google.cloud.pubsub.topic.v1.messagePublished"    trigger_region = "asia-northeast1"    pubsub_topic   = google_pubsub_topic.tftest.id    retry_policy   = "RETRY_POLICY_RETRY"  }}しかしこの場合だと、Cloud Functionsが失敗した際にメッセージを転送するDLQを設定することができない。理由としては、Pub/SubのDLQはサブスクリプションに対して設定するため、自動生成されるサブスクリプションはTerraformのコードで扱えないから。回避方法Pub/SubのPushサブスクリプションを使い、Cloud FunctionのHTTPエンドポイントを呼び出す。このHTTPトリガーはgoogle_cloudfunctions2_functionを作成すると自動で作られ、デフォルトでは呼び出しに認証が必要になる。この呼び出し方法だと、google_pubsub_subscriptionをTerraformで記述する必要があるので、その中でDLQが指定できる。resource "google_pubsub_subscription" "tftest_http" {  name                 = "tftest-http"  topic                = google_pubsub_topic.tftest.name  ack_deadline_seconds = 10  push_config {    push_endpoint = google_cloudfunctions2_function.image_transform.service_config[0].uri    attributes = {      x-goog-version = "v1"    }    oidc_token {      service_account_email = google_service_account.invoke_function_2.email    }  }  dead_letter_policy {    dead_letter_topic     = google_pubsub_topic.dead_letter_topic.id    max_delivery_attempts = 5  }  retry_policy {    minimum_backoff = "5s"    maximum_backoff = "30s"  }}resource "google_pubsub_topic" "dead_letter_topic" {  name                       = "dead-letter-topic"  message_retention_duration = "600s"}権限まわりサブスクリプションに紐づけるSAには次の権限が必要になるCloud Functionsを呼び出す権限roles/run.invokerロールが必要（Cloud Functions gen2の場合）なぜかCloud Runを呼び出す権限が必要になる（gen1の場合は素直にroles/cloudfunctions.invokerを付与すれば良い）GCPが提供するpubsubのSAには次の権限が必要になるSAにトークンを発行する権限DLQのトピックへメッセージを発行する権限メッセージに対して確認応答する権限（DLQに転送する際、元のキューから除去するために必要）Terraformでは次のようになるresource "google_service_account" "invoke_function_2" {  account_id   = "invoke-function-2"  display_name = "invoke-function-2"}resource "google_cloud_run_service_iam_member" "invoke" {  location = "asia-northeast1"  service  = google_cloudfunctions2_function.image_transform.name  role     = "roles/run.invoker"  member   = google_service_account.invoke_function_2.member}resource "google_project_iam_member" "project" {  project = data.google_project.self.id  role    = "roles/iam.serviceAccountTokenCreator"  member  = "serviceAccount:service-${data.google_project.self.number}@gcp-sa-pubsub.iam.gserviceaccount.com"}resource "google_pubsub_topic_iam_member" "publish_dlq" {  topic  = google_pubsub_topic.dead_letter_topic.id  role   = "roles/pubsub.publisher"  member = "serviceAccount:service-${data.google_project.self.number}@gcp-sa-pubsub.iam.gserviceaccount.com"}resource "google_pubsub_subscription_iam_member" "dequeue" {  subscription = google_pubsub_subscription.tftest_http.id  role         = "roles/pubsub.subscriber"  member       = "serviceAccount:service-${data.google_project.self.number}@gcp-sa-pubsub.iam.gserviceaccount.com"}おわりにPub/SubトリガーでCloud Functionsを呼び出す場合、TerraformでDLQの設定ができないという問題はProvider PluginのIssueにも上がっていたgithub.comGCP側にうまく扱えるAPIが無いらしい。残念。

Cloud Pub/SubとCloud Functions gen2の連携（with DLQ）

初めにCIがコケたらSlackに通知するというのは一般的なユースケースだと思います。特に、失敗したビルドを実行したユーザにだけメンションが飛ばせると便利ですね。ここでは会社のメールアドレス = Slackの登録メールアドレス = CircleCIの登録メールアドレスのようなよくある環境を想定します（CircleCIのEnterprise版を使っている場合）。実装CircleCIとSlackの連携方法ですが複数の方法があります。Slackが開発しているCircleCI apphttps://slack.com/apps/A0F7VRE7N-circleci?tab=more_infoこちらはSlack公式のappになります。インストールして設定するだけですぐに使えるものです。手軽ですがメンションを飛ばすことはできませんCircleCIのslack orbhttps://circleci.com/developer/orbs/orb/circleci/slackこちらはCircleCIの公式orbです。自作のSlack Appを作成してwebhookで呼び出す必要がありますが、メンションを付与できます。今回はこれを使います手順(1) Your Appsページに飛び、Create Appから適当な名前でAppを作りますhttps://api.slack.com/apps(2) OAuth & Permissions > Scopesで必要なスコープをつけます必要なスコープは以下の通りですchat:writechat:write.publicincoming-webhookusers:readusers:read.emailアプリをSlackワークスペースに対して認証してSLACK_ACCESS_TOKENを入手します。(3) CircleCIのコマンド作成先ほどのSLACK_ACCESS_TOKENはProject VariablesやOrganizationのContextにセットしておき、ワークフロー中でロードされるようにしておきます。CCIでコマンドを作ります。commands:    notify-slack-when-fail:        steps:            - run:                command: |                    slack_user_id=$(curl -s -H "Authorization: Bearer $SLACK_ACCESS_TOKEN" "https://slack.com/api/users.lookupByEmail?email=$CIRCLE_USERNAME@example.com" | jq -r '.user.id')                    echo "export SLACK_PARAM_MENTIONS='<@$slack_user_id>'" >> $BASH_ENV                 when: on_fail            - slack/notify:                event: fail                channel: your_channel                template: basic_fail_1Slackの仕様上、APIからメンションに使えるのはSlackユーザIDという文字列です。普段Slack中でメンションを当てる時に使う@electrical-sheepのような名前は使えないので、API経由でクエリする必要がありますあとはこのコマンドをjob stepsの最後で使えば完了steps:    - checkout    - run:        command: ./terraform.sh     - notify-slack-when-fail

CircleCIのfailをSlackにメンション付きで通知する

Terraformのvariablesあるある（？）できたもの例my_resource.tfvariables.tfdev.tfvarsできないことTerraformのvariablesあるある（？）variablesブロックを変数ごとに書くのがめんどくさい。色々インフラの変更をした結果、未使用のvariablesが放置されがち1つ目に関しては変数の数が増えてきたら特にめんどくさくなります。大体の変数がstringかnumber型なので、variablesブロックも大体同じ感じの定義がずっと続くことになります。2つ目はtflintを毎回実行して未使用の変数を除去すれば良いのですが、不幸にもそれができていないまま変数が1000個くらいに膨れ上がってしまったプロジェクトもあったりします。そんなわけでvariables.tfをいい感じに生成してくれるツールを書きました。できたものgithub.comこれがやることはシンプルで、不足しているvariablesブロックを追加したvariables.tfを出力するsyncモードの時は、↑に加えてさらに未使用のvariablesブロックも削除するオプションをつけると、tfvarsファイルも一緒に整理する例それぞれ次のように定義されていたとします。my_resource.tfresource "my_resource" "myvar" {  url        = "http://semvar.co.jp/${var.appname}/${var.env}"  # title      = var.moge  expiration = var.expiration_days}variables.tfvariable "env" {}variable "unused" {  description = "my variable"}variable "appname" {  description = ""}dev.tfvarsenv = "dev"unused = {  "abc"  = "def"  "bird" = "owl"}appname = "myapp"実行結果はこうなります。$ tfv -sync --tfvars-file dev.tfvarsvariable "env" {}variable "appname" {  description = ""}variable "expiration_days" {  description = ""}使われてないunusedを除去し、定義されていないexpiration_daysを追加したものが出力されます。また、dev.tfvars.generatedにはこのようなファイルが生成されます。env = "dev"appname = "myapp"できないこと真面目にパーサを書いてないので、%{}を含む構文には対応していません。つまり、%{}で囲まれているvar.fooのような変数の利用があっても正しく認識されない場合があります。そもそも%{}をあまり見ないのでこれは何？って感じなんですが、これは文字列の中に制御構文を埋め込む記法です。developer.hashicorp.com公式サイトの例にあがっているのが次のような書き方です。"Hello, %{ if var.name != "" }${var.name}%{ else }unnamed%{ endif }!"%{}は再帰的な構造を持つことができるので、行ごとにGoのregexpでパターンマッチする方針だと上手く扱えませんでした。ただ%{}を使うことがあまりないので、大体のケースでなんとかなると思います。

Terraformのvariables.tfを生成するツールを作った

StepFunctionをlambda(Go 1.x)からキックするようなコードを書いてる時に、StartExecutionを呼び出すと次のようなエラーが出た。operation error SFN: StartExecution, https response error StatusCode: 400, RequestID: xxxx-xxxx-xxx-xxxx, api error MissingAuthenticationTokenException: Request is missing Authentication Token: OperationErrorlamdbaのロールを変更してみても解決せず、ggってもそれらしいのが出てこないのでなんだこれってなってた。原因clientをこのように定義していた。client := sfn.New(sfn.Options{    Region: "ap-northeast-1",})正しくはこう。cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithRegion("ap-northeast-1"))if err != nil {    log.Fatalf("unable to load SDK config, %v", err)}client := sfn.NewFromConfig(cfg)sfn.Newは返されるクライアントのカスタマイズ性がより高く、一方で環境からクレデンシャルを取ってくれないようだ。ちゃんとドキュメントは読もうな！

Request is missing Authentication Token: OperationErrorになる

ECSの文脈でヘルスチェックといえば、次の2通りが挙げられる。ELBのターゲットグループで指定するヘルスチェックタスク定義のコンテナ定義パラメータで指定するヘルスチェック1はECSではなくELBの機能なので、これら2つを組み合わせて使う場合に限定される。結論1.のELBによるヘルスチェックでは、「アプリケーションが新規のリクエストを受付できること」だけを検証するべき。例えば、"ok"などの単純な文字列を返したり、小さな静的コンテンツを返すようなパスを指定する。2.のコンテナヘルスチェックに関しては任意のコマンドが書けるためHTTPリクエストとは限らないが、方針としては1.と同じ。説明上記の2通りのヘルスチェックが失敗した場合はいずれもタスクが終了し、ECSスケジューラによって新たなタスクに置換される。そのため、タスク（コンテナ）を再起動するしか新たなリクエストを受付できない、あるいは終了するほかない場合に限り、ヘルスチェックを失敗させるべき。このような状況は次のようなケースが該当する。アプリケーションが完全にハングしたタスクのメモリ・ストレージが限界ハードウェア障害そのため、ヘルスチェックで実行される処理はこういった状況を検出できる必要十分なものに留める必要がある。逆に、DBや外部APIに接続するような処理を含むエンドポイントはヘルスチェックに指定すべきではない。これらの外部の依存が利用できない時はインフラ設定の不備によって疎通できない認証情報などの誤りで接続できない外部依存側の障害で接続できないなどが考えられるが、いずれも（特定のケースを除いて）ECSタスクを再起動して解決する問題ではない。その上、タスクが終了してしまうことによって、ecs execなどを使ったトラブルシューティングが難しくなる。ECSが再起動を繰り返すため、エンドユーザがアプリケーション自体に接続できなくなる。部分的にアプリケーションを利用したり、案内メッセージを出したりできないため、ユーザに対しては不親切。といった問題が生じる。DBや外部APIに接続するような処理を含むエンドポイントは、モニタリングの統合監視(Synthetics Monitoring)で利用するのが良さそう。補足よくECSの比較対象として挙げられるKubernetesでは、失敗時の挙動が異なる複数のヘルスチェックが用意されている。liveness probe: 失敗時は該当Podを終了させるrediness probe: 失敗時は該当Podにトラフィックが転送されないECSにはこれらの違いはなく、ヘルスチェックが失敗した場合はタスクが終了し、スケジューラによって新たなタスクに置換される。つまり、ECSはKubenetesで言うliveness probeの機能を持ったヘルスチェック機構しか持っていない（rediness probeに対応するヘルスチェック機構を求めるfeature requestはある）。

ECSヘルスチェックベストプラクティス

ISUCON12に向けて過去問をやっていたら、ISUCON11のベンチマーカーの実行に時間がかかっていたので高速化してみました。このベンチマーカーはアプリケーションに負荷をかけ始めるまでの初期化処理に結構時間がかかります。特にbench/random/image.goのinit()で大部分の時間を使っていました。func init() {    var files []fs.FileInfo    var err error    // 画像ファイル群の読み込み    files, err = ioutil.ReadDir(imageFolderPath)    if err != nil {        log.Fatalf("%+v", fmt.Errorf("%w", err))    }    for i := 0; i < imageNum; i++ {        fileInfo := files[rand.Intn(len(files))]        //default.jpg以外の、.jpgで終わるファイルに限定する        for fileInfo.Name() == "default.jpg" || !strings.HasSuffix(fileInfo.Name(), ".jpg") {            fileInfo = files[rand.Intn(len(files))]        }        img, err := imgio.Open(filepath.Join(imageFolderPath, fileInfo.Name()))        if err != nil {            log.Fatalf("%+v", err)        }        img = adjust.Brightness(img, float64(rand.Intn(20)-10)/10.0/2)        img = adjust.Contrast(img, float64(rand.Intn(20)-10)/10.0/2)        img = adjust.Gamma(img, 0.1+rand.Float64()*3)        img = adjust.Saturation(img, float64(rand.Intn(20)-10)/10.0/2)        //encode        buffer := new(bytes.Buffer)        encoder := imgio.JPEGEncoder(rand.Intn(95) + 5)        encoder(buffer, img)        images[i] = buffer.Bytes()    }}このコードでは、imageNum回の画像変換を直列実行しています。次のようにCPUのコア数分だけ並列で変換処理することで高速化できます。func init() {    var files []fs.FileInfo    var err error    // 画像ファイル群の読み込み    files, err = ioutil.ReadDir(imageFolderPath)    if err != nil {        log.Fatalf("%+v", fmt.Errorf("%w", err))    }    type imageInfo struct {        name string        i    int    }    ch := make(chan imageInfo, imageNum)    for i := 0; i < imageNum; i++ {        fileInfo := files[rand.Intn(len(files))]        //default.jpg以外の、.jpgで終わるファイルに限定する        for fileInfo.Name() == "default.jpg" || !strings.HasSuffix(fileInfo.Name(), ".jpg") {            fileInfo = files[rand.Intn(len(files))]        }        ch <- imageInfo{fileInfo.Name(), i}    }    close(ch)    var wg sync.WaitGroup    for j := 0; j < runtime.NumCPU(); j++ {        wg.Add(1)        go func(ch chan imageInfo) {            for c := range ch {                img, err := imgio.Open(filepath.Join(imageFolderPath, c.name))                if err != nil {                    log.Fatalf("%+v", err)                }                img = adjust.Brightness(img, float64(rand.Intn(20)-10)/10.0/2)                img = adjust.Contrast(img, float64(rand.Intn(20)-10)/10.0/2)                img = adjust.Gamma(img, 0.1+rand.Float64()*3)                img = adjust.Saturation(img, float64(rand.Intn(20)-10)/10.0/2)                //encode                buffer := new(bytes.Buffer)                encoder := imgio.JPEGEncoder(rand.Intn(95) + 5)                encoder(buffer, img)                images[c.i] = buffer.Bytes()                fmt.Println("image:", c.i)            }            wg.Done()        }(ch)    }    wg.Wait()}（もう少し工夫すればchan imageInfoのバッファは不要のはず）起動からベンチマーク開始までの時間はc6i.2xlargeのインスタンスで1m44s→39sと63%ほど速くなりました。ベンチマーカーの周囲のコードを読んでないので、元の実装で何か意図があって並列化してないのか、さらに言えば画像を実行時に毎度変換処理する必要があるのかはよく分かっていません...とりあえず高速にベンチ回せるようになったのでこれで良いことにします。

ISUCON11のベンチマーカーを高速化

あるプロダクトの監視にはNewRelicを使っているが、手作業で作られたNewRelicのアラートが大量に放置されていた。そのため、どのアラートが作成されているのかがわからない、不要なものもわからない、レビューがやりにくいといった問題があった。そこでTerraformerを使ってそれらを取り込みコード化することができたので、方法を記載する。Terraformergithub.comリソースからTerraformのコード+tfstateを自動で生成するツール。Terraformerを使わなくてもterraform importコマンドを使うことでリソースを取り込むことはできるが、Terraformerを使うことのメリットは次の通り。tfstateとコードを両方生成してくれる。対してterraform importはtfstateのみ生成。複数のリソースを一括で取り込める。対してterraform importは1リソースだけ。リソースをTerraformで作成するときと同様、取り込みたいリソースのprovider pluginが必要となる。TerraformerはNewRelicに対応しているはずだったが、いざ試してみると依存しているNewRelicクライアントが古すぎて失敗したため、新しいクライアントで入れ替えた。github.comこのPRがマージされたコードが先日リリースされたため、誰でもNewRelicリソースを取り込めるようになった。やったぜ。brew installするなりgithubのreleaseから取ってくるなりして利用できる。リソース取り込みTerraformerは残念ながらTerraform 0.13にしか対応していないため、まずtfenvを使ってバージョンを下げる。$ tfenv install 0.13.0$ tfenv use 0.13.0NewRelicのprovider pluginを.terraform.d/plugins/<system>に配置する。これをやらないとfork/exec : no such file or directoryみたいなエラーが出て動かない。M1 Macならこんな感じになる。$ cd .terraform.d/plugins/darwin_arm64$ curl -LO https://github.com/newrelic/terraform-provider-newrelic/releases/download/v2.45.1/terraform-provider-newrelic_2.45.1_darwin_arm64.zip$ unzip terraform-provider-newrelic_2.45.1_darwin_arm64.zipリソースを取り込んでみる。今のところ対応しているのはalert, infra, syntheticsの3種類。$ terraformer import newrelic -r alert,infra,synthetics --api-key=$API_KEY --account-id=$ACCOUNT_IDgenerated/newrelicに各種リソースのコードが生成された。.└── generated    └── newrelic        ├── alert        │   ├── alert_channel.tf        │   ├── alert_policy.tf        │   ├── nrql_alert_condition.tf        │   ├── outputs.tf        │   ├── provider.tf        │   └── terraform.tfstate        ├── infra        │   ├── provider.tf        │   └── terraform.tfstate        └── synthetics            ├── outputs.tf            ├── provider.tf            ├── synthetics_monitor.tf            └── terraform.tfstateそれぞれの./generated/newrelic/<resource>にnewrelicの設定を記述する。provider "newrelic" {  region     = "US"  account_id = var.nr_account_id  api_key    = var.nr_api_key}variable "nr_account_id" {}variable "nr_api_key" {}planしてみて差分が出なければ取り込み完了。$ export TF_VAR_nr_account_id=$ACCOUNT_ID$ export TF_VAR_nr_api_key=$API_KEY$ terraform 0.13upgrade .$ terraform init$ terraform plan取り込んだ後はTerraformの最新バージョンを使うことができるので、公式のUpgrade Guideを見ながらちまちまアップグレードする。

TerraformerでNewRelicのリソースをTerraformに取り込めるようにした

メール認証の仕組みと、SESでのTerraformを使った設定方法について紹介します。メール認証の種類メールメッセージMAIL FROMFROMSPF(Sender Policy Framework)DKIM(DomainKeys Identified Mail)DMARCSESの設定SESで利用するドメイン認証DKIM設定DMARC with DKIMDMARC with SPF参考メール認証の種類メールでは送信元のなりすましを検出するための認証の仕組みとして、主に以下の3つがあります。それぞれRFCで定められています。SPF(Sender Policy Framework)DKIM(DomainKeys Identified Mail)DMARC(Domain-based Message Authentication, Reporting, and Conformance)メールメッセージSMTPで送信されるメールオブジェクトの構造は次のようになっています。envelope: 送信元アドレス(MAIL FROM)、受信者アドレスなどを含むセクションcontentheader: 送受信者、cc, bccなどを含むセクションbody: メール本文を含むセクションenvelopeとcontentの2つのセクションがあり、さらにcontentはheaderとbodyに分けられます。ここで着目すべきなのは、envelopeとcontent headerの両方に送信元を表す情報があることです。MAIL FROMenvelopeに記載される送信元の情報です。ここにはエラーレポートのために使われるメールボックスのアドレスが記載されます。Return-Path, envelope fromなどの別名があります。FROMcontent headerに記載される送信元の情報です。ここには送信者のメールボックスのアドレスが記載されます。SPF(Sender Policy Framework)送信元ホストを認証するための仕組みです。RFC7208に記載があります。ドメインの所有者は、どのホストからメールが送信できるかを表すSPFレコード(TXTレコード)をDNSサーバに登録します。メールを受信したメールサーバは、MAIL FROMのドメイン名を使ってSPFレコードを問い合わせ、メールが正規のサーバから送信されたものかをチェックします。DKIM(DomainKeys Identified Mail)送信元ホストの認証、メッセージの改竄検出をするための仕組みです。RFC6376に記載があります。DKIMでは、送信側サーバがメールのハッシュ値に対して署名を付けます。検証鍵（公開鍵）はDNSのレコードとして公開し、受信側がその鍵を使ってメールの検証をすることで、ドメインのなりすましと改ざんを検出することができます。DMARCSPFやDKIMで認証失敗したメールに対するハンドリングポリシーやレポーティングを提供する仕組みです。RFC7489に記載があります。送信側のドメイン所有者は、SPFやDKIMで認証失敗したメールに対するハンドリングポリシー、それらのレポーティングメールを送信する宛先メールアドレスをDNSのレコードとして公開します。受信側はドメインごとに認証失敗時の動作を決定することができて、送信側はSPFやDKIMの効果を知ることができるといったメリットがあります。SESの設定SESで利用するドメイン認証これら3つをTerraformで設定していきます。それらを行う前に、まずSESで使う送信元メールアドレスのドメインを認証する必要があります。これを行わない限りSESでメールを送信することはできません。個別で送信元メールアドレスを認証することもできますが、ドメインレベルで認証することで、そのドメインを持つすべてのメールアドレスから送信が可能になります。送信元ドメインには別途取得したblacksheep.linkを利用しています。resource "aws_ses_domain_identity" "this" {  domain = var.domain_name}resource "aws_route53_record" "verify" {  zone_id = var.zone_id  name    = "_amazonses.${var.domain_name}"  type    = "TXT"  ttl     = "600"  records = [aws_ses_domain_identity.this.verification_token]}実はこの状態で既にSPF, DKIMに合格します。試しにAWSコンソールにあるSend test emailからメールを送信してみます。（SESがSandbox modeの場合はこの時の送信先メールアドレスは認証されている必要があります）画像はGmailに送信したメールのソースを表示してみた結果です。SPF, DKIM共にPASSとなっています。これは、SESが気を利かせてamazonses.comのDNSレコードに必要な情報を登録しているからだと推測できます。認証結果を表すヘッダは次のようになっていました。自ドメインに対するDKIMは鍵を登録していないため失敗し、amazonses.comに対するDKIMは成功しています。SPFもap-northeast-1.amazonses.comドメインにおいて成功しています。Authentication-Results: mx.google.com;    dkim=temperror (no key for signature) header.i=@blacksheep.link header.s=ifivvwdq3hqh3nh5uxmqyauex25puggo header.b=XECBGecj;    dkim=pass header.i=@amazonses.com header.s=wf7ez2pjvcsodozkoqksj277kza7wu47 header.b=NcJ3gCOn;    spf=pass (google.com: domain of 0106017f5e045354-a5a80a0d-8064-4d3b-b44c-245d73ef7c3b-000000@ap-northeast-1.amazonses.com designates 23.251.234.8 as permitted sender) smtp.mailfrom=0106017f5e045354-a5a80a0d-8064-4d3b-b44c-245d73ef7c3b-000000@ap-northeast-1.amazonses.comただし、このままではDMARCを自ドメインに対して設定することはできません。DKIM設定自ドメインに対してDKIMの設定をします。DKIMの設定もidentityとそれに対応するDNSのレコードになります。dkim_tokensがapply後にしか取得できない値のため、まずはaws_ses_domain_dkimだけapplyし、その後aws_route53_recordのコメントアウトを外して実行する必要があります。resource "aws_ses_domain_dkim" "this" {  domain = aws_ses_domain_identity.this.domain}# resource "aws_route53_record" "dkim" {#   for_each = toset(aws_ses_domain_dkim.this.dkim_tokens)#   zone_id = var.zone_id#   name    = "${each.value}._domainkey.${var.domain_name}"#   type    = "CNAME"#   ttl     = "600"#   records = ["${each.value}.dkim.amazonses.com"]# }この状態でメールを再度送信すると、DKIMのドメインがblacksheep.linkとなっているのが分かります。DMARC with DKIMDMARCはDKIM, SPF, またはその両方の情報を使って設定することができます。最低限DKIMかSPFのどちらか片方の設定が自ドメインに対して適切に行われていないと準拠することはできません。先ほどDKIMを自ドメインに対して設定したので、このセクションではDKIMを使ったDMARCが有効になります。DMARCの設定は_dmarc.blacksheep.linkに対してTXTレコードを1つ追加するだけです。レコードには;で区切られた情報が入っており、p=で認証失敗時のハンドリング方法(none=何もしない, quarantine=スパムフォルダ行き, reject=受信拒否)でruaでレポートの送信先アドレスを指定します。他にもpct=で DMARCポリシーを適応する割合を指定できたりします。resource "aws_route53_record" "dmarc" {  zone_id = var.zone_id  name    = "_dmarc.${aws_ses_domain_identity.this.domain}"  type    = "TXT"  ttl     = "60"  records = ["v=DMARC1;p=none;rua=mailto:dmarc-reports@${aws_ses_domain_identity.this.domain}"]}この状態でメールを送信してみると、DMARCがPASSになっているのが分かります（DNSの設定から数分待たないと有効にならない時があるようです）。DMARC with SPFさて、ここまででSPF, DKIM, DMARCを有効にできました。このままでも問題はないのですが、SPFを使ったDMARCの準拠も紹介しておきます。まずはSPFチェックが自ドメインに対して通るように設定します。SPFではMAIL FROMを利用して送信元の検証を行うため、カスタムのMAIL FROMを設定します。検証されたドメイン（aws_ses_domain_identityで設定したドメイン）のサブドメインである必要があります。resource "aws_ses_domain_mail_from" "this" {  domain           = aws_ses_domain_identity.this.domain  mail_from_domain = "bounce.${aws_ses_domain_identity.this.domain}"}resource "aws_route53_record" "mail_from_mx" {  zone_id = var.zone_id  name    = aws_ses_domain_mail_from.this.mail_from_domain  type    = "MX"  ttl     = "600"  records = ["10 feedback-smtp.ap-northeast-1.amazonses.com"]}続いてカスタムのMAIL FROMドメインに対してSPFを設定します。1つ注意点として、docomoやauといったキャリアは独自のなりすまし対策としてMAIL FROMと共にFROMのドメインをチェックするようです。そのため、FROMに設定しているaws_ses_domain_identity.this.domainに対してもSPFのTXTレコードを登録しています。実際に送信元メールサーバのIPアドレス情報を持っているのはamazonses.comのゾーンにあるため、いずれもincludeを使って解決を委譲しています。resource "aws_route53_record" "spf" {  zone_id = var.zone_id  name    = aws_ses_domain_mail_from.this.mail_from_domain  type    = "TXT"  ttl     = "600"  records = ["v=spf1 include:amazonses.com ~all"]}# ヘッダFROMのドメインもSPFレコードに登録するのは、キャリアメールが届くようにするため# https://qiita.com/shouta-dev/items/a33c55e0df154012c557resource "aws_route53_record" "spf_career" {  zone_id = var.zone_id  name    = aws_ses_domain_identity.this.domain  type    = "TXT"  ttl     = "600"  records = ["v=spf1 include:amazonses.com ~all"]}これでSPFを使ったDMARCが有効になりました。SPF, DKIM, DMARCをすべてパスしたメールのAuthentication-Resultsは次のようになります。Authentication-Results: mx.google.com;    dkim=pass header.i=@blacksheep.link header.s=ifivvwdq3hqh3nh5uxmqyauex25puggo header.b=XC7mjg2c;    dkim=pass header.i=@amazonses.com header.s=wf7ez2pjvcsodozkoqksj277kza7wu47 header.b=QHVEVzHZ;    spf=pass (google.com: domain of 0106017f5e4de53b-0911b2ea-3b0f-49c9-988b-636be36684cd-000000@bounce.blacksheep.link designates 23.251.234.9 as permitted sender) smtp.mailfrom=0106017f5e4de53b-0911b2ea-3b0f-49c9-988b-636be36684cd-000000@bounce.blacksheep.link;    dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=blacksheep.link参考https://dmarc.org/overview/https://qiita.com/shouta-dev/items/a33c55e0df154012c557https://ent.iij.ad.jp/articles/172/https://www.sparkpost.com/resources/email-explained/return-path-explained/

AWS SESで信頼性の高いメール送信(SPF, DKIM, DMARC) with Terraform

バッチ処理基盤をEC2からECSへと移行させるにあたって考えたこと、Terraformでの構築方法をメモしておきます。本稿で単にECSと書いた場合は全てECS Fargateを指しています。移行の背景移行にあたっての考慮点どのサービスを使うか構築注意点参考移行の背景元々はEC2+cronという昔ながらの構成でバッチ処理を定期実行していましたが、以下のような理由からコンテナ化、マネージドサービス化を行いました。EC2のOSレイヤの運用がしんどくなっていたサーバにログインして設定変更するオペレーションが常態化しており、色々と構成管理できていなかった各種パッケージミドルウェアのconf各種パラメータジョブのオンオフ切り替え、パラメータの変更などのたびにサーバにログインするオペレーションコストが掛かっていた移行にあたっての考慮点ジョブはgraceful shutdownするか処理を確実に行うため、実行基盤の終了時にジョブが中途半端な状態で中止されないことが必要でした。実行基盤の終了は、一般的にコンソールやコマンドからの停止、スケールイン、インプレースなデプロイ、メインプロセスの終了などで発生します。ジョブは長いものだと数時間という期間にわたって実行されるため、特に新たなバージョンがデプロイされた際に実行中のジョブが強制中断されないかといったことに注意する必要がありました。各ジョブを個別のクラウドリソースとして扱うことができるかEC2+cronといった構成だと、ジョブは全て1つのサーバの中に入れられてサーバ内のファイルでまとめて管理する必要があります。ジョブの情報はサーバの外からは見ることができないため、特定のジョブを操作する場合はサーバにログインしなくてはなりません。個別にジョブを扱うことができると、ジョブの特性や要求に応じたリソース割り当てが可能になったり、メンテの時に特定のジョブだけaws cliからオフにできたりするため運用の幅が広がります。どのサービスを使うかAWSでバッチジョブを動かすために使えるサービスは複数あります。EC2, ECS Serviceなどのコンピューティング基盤でcronを動かすEC2は上述の通りECS Serviceはコンテナ化という目的は達成できますが、考慮点の2つを満たすことができません。特に新たなバージョンをリリースする際にローリングアップデートで実行中のジョブコンテナが終了されてしまうので、長時間かかるジョブの実行中はリリースができないという制約があります。なお、ECS自体にはGraceful Shutdownをサポートする仕組みがありますタスクの終了処理開始時にはSIGTERM、指定時間後（120sまで）にSIGKILLがコンテナのPID1のプロセスに送信されたのちタスクが解放されます。コンテナのプロセスが正しくシグナルハンドリングを行えばGracefulにシャットダウンすることが可能です。LaravelのQueue Workerのようなジョブを実行する際はECS Serviceの方が向いていると思いますhttps://aws.amazon.com/jp/blogs/news/graceful-shutdowns-with-ecs/ECS ScheduledTaskECSのタスクをcron/rate式で起動できる機能です。コンテナ化の他に、上述の考慮点を2つとも満たすことができます。新パージョンのデプロイ時はコンテナレジストリにイメージをpushしてイベントターゲットを更新するだけで、実行中のタスクに影響しません。次回実行時からは新たなコンテナイメージが使われます。タスク終了時はECSの機能でGraceful Shutdownが行われます。1つのジョブは1つのタスクと紐づくため、各ジョブを個別のリソースとして扱うことができます。ContainerOverridesをうまく使うことでコードベースが同じなら各ジョブ間で同じコンテナイメージを使い回すことができますなおECSとは関係ないですが、タスク起動のトリガーに使うEventBridgeはまれに一度に複数回イベントを送信することがあるため、ジョブは同時に複数回実行されても問題ない作りになっている必要があります。LambdaLambda Containerとカスタムランタイムを使うことで任意の言語で処理を実行できます。上述の考慮点は満たしますが、ECSでいうContainerOverridesの機能がないためジョブごとに別のコンテナをビルドする必要があります。15分間でタイムアウトするため、長時間のジョブ実行には向いていません。BatchEC2やECSをバックエンドとしてジョブを実行できます。依存関係を持つジョブやリトライの制御など高度なことができます。考慮点は2つとも満たせますこれらの候補の中からECS ScheduledTaskを選択しました。上述のメリットに加え、すでにECSのクラスタをAPIサーバとして利用していたこと、Batchほど豊富な機能を必要としていなかった（あとあまり知見がなかった）ことが主な理由です。構築Terraformでの例を示します。ScheduledTaskはaws_ecs_*のリソースではなくてCloudWatchのイベントターゲット+イベントルールになります。inputでContainerOverridesを指定し、外部からコマンドを上書きすることで同じコンテナイメージを複数のジョブで使い回すことができます（起動スクリプトの引数などでジョブの種類を指定できるようになっている必要があります）。ECSのクラスタやタスク定義、各種ロールなどは割愛します。resource "aws_cloudwatch_event_target" "this" {  target_id = var.target_id  arn       = var.cluster_arn  rule      = aws_cloudwatch_event_rule.this.name  role_arn  = var.role_arn  ecs_target {    task_count             = 1    task_definition_arn    = var.taskdef_arn    launch_type            = "FARGATE"    platform_version       = "1.4.0"    enable_execute_command = true    network_configuration {      subnets = var.private_subnets    }  }  input = jsonencode(    {      "containerOverrides" : [        {          "name" : var.container_name,          "command" : var.command        }      ]    }  )  lifecycle {    ignore_changes = [ecs_target[0].task_definition_arn]  }}resource "aws_cloudwatch_event_rule" "this" {  name                = var.rule_name  is_enabled          = var.is_enabled  schedule_expression = var.schedule_expression}上記のモジュールの呼び出し側は次のようになります。module "sample" {  source              = "./ecs_scheduled_task"  target_id           = "sample"  rule_name           = "sample"  container_name      = "batch"  schedule_expression = "cron(* * * * ? *)"  cluster_arn         = aws_ecs_cluster.example.arn  role_arn            = module.ecs_events_role.iam_role_arn  taskdef_arn         = aws_ecs_task_definition.batch.arn  private_subnets     = [aws_subnet.private_0.id, aws_subnet.private_1.id]  command             = ["/bin/my_batch.sh", "job_name"]  is_enabled          = true}CIは次のような感じになりますコンテナイメージをビルドタスク定義のタグを書き換えてaws ecs register-task-definitionする更新したタスク定義でaws events put-targetsする注意点ScheduledTaskはジョブ起動の度に毎回コンテナイメージをpullします。そのため、起動頻度の高いタスクをプライベートサブネットで起動する場合は、NATゲートウェイの転送費用が思いの外高くなる場合があります。このような場合はECRとS3に対してVPCエンドポイントを作成し、NATゲートウェイを迂回することが有効です。https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/vpc-endpoints.html参考https://registry.terraform.io/providers/hashicorp/aws/3.74.1/docshttps://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/scheduled_tasks.htmlhttps://aws.amazon.com/jp/blogs/news/new-for-aws-lambda-container-image-support/

バッチ処理の基盤をEC2からECSに移行する

zshのプロンプトをいい感じにするのに普段pureを使っている。しかし新調したM1 macbookだとインストールガイドの通りにやっても上手く読み込んでくれなかった解決法このIssueについているコメントの通りにやることで解決したgithub.com.zshrcには次のように記述する。x86のmacとfpathの値が違うっぽい。fpath+=/opt/homebrew/share/zsh/site-functionsautoload -U promptinit; promptinitprompt pure

【zsh】pure-promptをM1 macで使う

CircleCIでcheckoutしたらいきなりこんなエラーが出てきた。error cloning repository: unknown error: ERROR: You're using an RSA key with SHA-1, which is no longer allowed. Please use a newer client or a different key type.特に前回パスしたビルドから大きく変更していない。何もしてないのに壊れましたとはまさにこのことである。このエラーの直前の行で次のようなwarningが出力されていた。Either git or ssh (required by git to clone through SSH) is not installed in the image. Falling back to CircleCI's native git client but the behavior may be different from official git. If this is an issue, please use an image that has official git and ssh installed.Cloning git repository「イメージにgitもsshも含まれていないため、CCIに含まれるgitクライアントにフォールバックしたよ。これがまずければビルドで使うイメージにgitクライアントを含めてね」と書いてある。そのためcheckoutの前でgitをインストールしてみた。    steps:      - run: yum install -y git      - checkoutこれでエラーは消えた。原因と思われるものnulab.comOpenSSH8.8から、SHA1ハッシュを使ったRSA署名が禁止されている先程のwarning行は以前のパスしたジョブでも出力されていたため、以前からこのジョブではCCIに含まれるネイティブのgitクライアントが使われていた。最近になって内部で使われるopensshのバージョンが上がり、今回のようなエラーが出たのだと思われる（追記参照）追記GitHub側の仕様変更が原因だった説が濃厚。表にもあるとおり、今日（2022/01/11）で非推奨の鍵を受け付けないようになっている。github.blog

CircleCIのcheckoutステップで失敗する

組織内部で管理しているプライベートリポジトリのライブラリなどを使いたい時は、CircleCIがそのリポジトリに対するアクセス権限を持っている必要があります。普通にプロジェクトをセットアップした場合、CCIのExecutorはそのプロジェクトに対するアクセス権限しか持っていないため、別のリポジトリへのアクセスは通常拒否されます。例えば、composer installした時に次のようなエラーが出た場合がそれに該当します。Cloning into '/var/www/html/vendor/proj/libs'...error: cannot run ssh: Not Foundfatal: unable to forkこういった操作はuser keyを使うことで可能になります。2種類のkey鍵はCCIコンソールのProject Settings > SSH keysで設定できます。deploy keydeploy keyを使うことで単一のリポジトリに対する権限を持つことができます。CCIのコンソールからGitHubのプロジェクトをセットアップすると、自動的にこのdeploy keyが作成され、GitHub側には公開鍵、CCI側が内部的に秘密鍵を設定します。この認証情報をもとにリポジトリのコードのcheckoutが行われます。user keyuser keyを使うことで、あるGitHubユーザと同等の権限を持つことができます。あるGitHubユーザというのはCCIのコンソール画面でuser keyを設定するために認証したユーザのことです。そのため、そのユーザがアクセスできる全てのリポジトリにCCIがアクセスできるようになります。machine useruser keyを設定すれば他のプライベートなリポジトリにもアクセスできますが、それを設定したユーザの見られたくないリポジトリにもアクセスできてしまいます。そのため、依存リポジトリへのアクセスに限定した専用のユーザを作成するのが望ましいとされています。そのようなユーザはmachine userと呼ばれます。注意点このuser keyはCCI Executorの.sshディレクトリにインストールされます。そのため、Executorの中で直接composer updateやらgo mod downloadする場合は問題ないですが、Dockerイメージをビルドする際はうまくいきません。そのときはリポジトリの中に依存リポジトリに対するdeploy keyを持たせて、Dockerfileでその鍵を指定する方法があります。COPY pull_key /root/.ssh/id_rsaRUN chmod 600 /root/.ssh/id_rsaENV GIT_SSH_COMMAND="ssh -i /root/.ssh/id_rsa -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"

外部のプライベートリポジトリへの依存がある時にCircleCIでビルドする

JSONのチェックくらいjqでやればええやろ、そう思っていた時期が私にもありました。背景ECSのタスク定義など、${foo}みたいな環境変数をJSONに含めることは結構あります。例えばこういうのですね。{    "name": "main",    "image": "${IMAGE_NAME}",    "essential": true,    "portMappings": [        {            "protocol": "tcp",            "containerPort": ${PORT}        }    ]}このJSONは${IMAGE_NAME}と${PORT}を設定すると正しいJSONになります。$ IMAGE_NAME=Foo PORT=80 envsubst < sample.json.template | jq{  "name": "main",  "image": "Foo",  "essential": true,  "portMappings": [    {      "protocol": "tcp",      "containerPort": 80    }  ]}実はここは${IMAGE_NAME}を設定しなくても、"${IMAGE_NAME}"が""（空文字）に置換されるのでJSON的には正しくなります。ただし、${PORT}のような数値はそういうわけにも行きません。"containerPort":のような形で残ってしまうため、環境変数の設定をしないとjqによる検証は失敗します。これではシンタックスの誤りが含まれているのか、環境変数がセットされていないだけなのかが分かりません。そこでJSONのシンタックスをチェックしたいだけなのに、いちいち環境変数を集めるのは面倒ですね。そんなわけで環境変数をロードしなくてもシンタックスだけチェックしてくれるツールを書きましたgithub.com$ jv sample.json.templateシンタックスが正しい（もし環境変数がセットされていれば正しいJSONになる）のでこれはパスします。${PORT}の直後にカンマを入れてみましょう。これで環境変数がセットされていたとしても不正なJSONになります。{    "name": "main",    "image": "${IMAGE_NAME}",    "essential": true,    "portMappings": [        {            "protocol": "tcp",            "containerPort": ${PORT},        }    ]}$ jv sample.json.templatesyntax error at line 9        }          ^^^invalid character '}' looking for beginning of object key stringあとがきまあこのツール、${foo}みたいなのを全部0に置換してから検証してるだけなんですけどね...

JSONを書くのが1ミリくらい楽になるシンタックスチェッカーを書いた

cloudfrontでコンテンツ配信をする際、Terraformであれば次のようにlogging_configを指定することでアクセスログを残すことができる。resource "aws_cloudfront_distribution" "example" {  ...  logging_config {    bucket = aws_s3_bucket.cloudfront_log.bucket_domain_name    prefix = "log/"  }  ...}resource "aws_s3_bucket" "cloudfront_log" {  bucket = "cloudfront-log"  versioning {    enabled = true  }}ただし、このままではバケットにログが送信されて来なかった。原因はアクセス権限不足。ドキュメントにある通り、awslogsdeliveryアカウントのACLアクセス許可が必要だった。ログバケットでは次のように指定する。resource "aws_s3_bucket" "cloudfront_log" {  bucket = "cloudfront-log"  versioning {    enabled = true  }  grant {    // awslogsdeliveryのアカウントID    // https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html    id = "c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0"    permissions = [      "FULL_CONTROL",    ]    type = "CanonicalUser"  }}

cloudfrontでログバケットにログが流れてこない

「何もしてないのに壊れました」というふざけたチーム名で会社の同期(kypくん、shikiさん)とisucon11の予選に参戦しました。使用言語はGo、結果は42525点、93位/約600チームで予選敗退でした。前日までにやったこと当日-20分0分+30分+2時間+4時間+6時間+7時間+8.5時間競技を終えて追記前日までにやったことチームで1回だけ役割分担・作業方針を確認しました。私のチームでは次のような方針を立てていました。おそらく3台のマシンが与えられるので、最初は各自が1台ずつ自由にデプロイ・ベンチをとって良いスコアを目指すいい感じのスコアができたらPR出してマージ1台構成で限界が見えてきたら複数台にして、appとDBを分ける全員が独立してデプロイ・ベンチができるというのがポイントで、自由に色々といじったりデバッグしたりする時間が取れて良かったです。デプロイはLinux向けにクロスコンパイルしたGoのバイナリをscpでデプロイするスクリプトを書いてました。チームでの方針確認以外には各自で対策してねといった感じで、個人的にはMySQLのトランザクションモデルを叩き込んだり、インデックスの張り方を復習したり、過去問対策をしていました。当日-20分全員が最も心配された起床試験を無事合格し、公式のライブ動画を見るところから開始でした。今年はISUCONDITIONというWebアプリがテーマで、全国の椅子の状態が大量に送信されてくるので、それを確認できるダッシュボード付きのアプリケーションを高速化しようといったものでした。0分開始と同時にマニュアルの重厚さにやや圧倒されつつチームでざっと読み合わせをしました。ここを疎かにすると失格になったりするので気をつけました。特に、AWSのセキュリティグループを変更してはいけないというルールは重要でしたね。+30分最初のベンチで2000点くらいでした。ここまでやったことは以下ツールのインストール・計測・その他ufwやAppArmorを無効にするスクリプトを入れるMariaDBのスロークエリやその他最低限の設定bind-address            = 0.0.0.0key_buffer_size = 1Gdisable_log_binslow_query_log         = 1slow_query_log_file    = /var/log/mysql/mysql-slow.loglong_query_time = 0Nginxのログ設定ベンチマークをとった後にkataribe + access.logでAPIごとのレスポンスタイムを、pt-query-digest + mysql-slow.logで全クエリの計測結果を集計して、チームのDiscordに投げていました。Discordに投げるのは去年isucon10で同じチームだったayumin君が作ったlog2discordを改造して使っていました。SQLログ出力go-sql-proxyを使ってアプリケーションログにSQLを出力させるような設定をしました。今回はそれほど見ることはありませんでしたが、APIごとに発行されているSQLが分かって便利です。+2時間とったベンチマークをヒントにしつつ、全員で怪しそうな関数やその改善案を出し合ったり、マニュアルを読み込んだりしていました。まず、dstatの結果から明らかに書き込み（POST /api/condition/*）が多いことがわかりました。全国の椅子からコンディションが送られてくる（という設定）なので当然ですね。さらにソースコードを見るとこんな面白いTODOが書いてあり、負荷を下げるため9割のリクエストを落としていました。// TODO: 一定割合リクエストを落としてしのぐようにしたが、本来は全量さばけるようにすべきdropProbability := 0.9if rand.Float64() <= dropProbability {    // c.Logger().Warnf("drop post isu condition request")    return c.NoContent(http.StatusAccepted)}ここの書き込みをMariaDBではなくRedisに逃して、MariaDBには遅延書き込みするといった案が出ました。また、スロークエリに以下のようなクエリがあったので、実行計画を見つつisu_conditionの(jia_isu_uuid, timestamp)にインデックスを貼りました。これだけで一気にスコアが18000くらいになりました。SELECT * FROM `isu_condition` WHERE `jia_isu_uuid` = '<uuid>' ORDER BY `timestamp` DESC LIMIT 1+4時間kypくんが/api/isuのN+1の修正、shikiさんがメモリに載せれそうなところをオンメモキャッシュに、私がPOST /api/condition/*の対応を担当してもくもくしていました。書き込みのRedis移行に関しては知識が貧弱だったため断念し、とりあえずbulk insertすることで対応しました。kypくん、shikiさんともに実装をマージしてもらいこの時点でスコアは20000~30000くらいでした+6時間POST /api/condition/*は非同期で書き込めるということだったので、リクエストごとではなく、1秒ごとにbulk insertするように変更しました。またこの頃になるとappのCPU使用率が支配的になっていたので、appサーバ2台 + DBサーバ1台の構成に変更しました。この間にshikiさんがgenerateIsuGraphResponseの取得件数を全件→1日分だけに絞るようなクエリを書いてくれたり、kyp君が外部APIで使っているhttpクライアントを差し替えたりしてくれました。これらの変更により大体40000点くらいまで上がりました。一瞬だけYouTube Liveで実況されていたランキングにチームが乗り、チームが沸きましたw23位！！+7時間この辺りでスコアボードが凍結されましたが、ポータルの障害でベンチが取れない時間が続きました。競技時間が若干延長されるということでやり残していた修正を行いました。GET /api/trendのN+1修正POST /api/isuがINSERT→UPDATEとなっているのをINSERT1つにまとめ、トランザクションを消すただしこれは時間の関係でマージできなかった+8.5時間競技終了が近くなってきたので再起動試験を行おうとしたのですが、なぜがAWSコンソールが重くてなかなかインスタンスが終了、起動しませんでした。さらに1度目の再起動ではDBサーバへの接続でミスがありアプリケーションの起動がうまくいってませんでした。やばいやばいと言いながら修正したものの、もう一度再起動試験をする時間はありませんでした（この時点で残り2分くらい）。結局、「統合テストはパス！ぶっつけ本番で行くわよ！！」というエヴァでありがちな方針をとったところでタイムアップとなりました。競技を終えて運営による再起動試験は運よくパスしていましたが、普通に危ないのでちゃんと時間をとってやりましょうというのが感想というか教訓です（それはそう）。予選落ちではあったものの、何もできずに惨敗した去年よりは成長を感じられて良かったです。来年はソロで出て自分一人の力試しするのもアリかもなーと思いました（ただ、チームで出るのもワイワイできて楽しかったので悩ましい）。運営の皆さん、楽しい大会をありがとうございました。追記isuconのMVができたそうです(?)かっこいいですね。www.youtube.com

isucon11予選に参戦してきました

概要Post \"https://cognito-idp.ap-northeast-1.amazonaws.com/\": x509: certificate signed by unknown authority"プログラムからAWSのリソース（今回はcognito）にアクセスしようとしたときにこのようなエラーになった。利用していたDockerfileは次の通り。Golangのアプリケーションをマルチステージビルドして、実行イメージとしてはDebian slimを利用した。FROM golang:1.16 AS builderWORKDIR /srcCOPY go.mod go.sum ./RUN go mod downloadCOPY app ./appCOPY main.go ./RUN go build -ldflags="-w -s" -o myappFROM debian:10-slimCOPY --from=builder /src/myapp .EXPOSE 8080CMD [ "./myapp" ]原因なんとなくAWSのロールやポリシー周りのミスかと思いきやそうではなく、証明書にまつわるエラーだった。AWS SDKはAPIリクエストを投げるときにTLSを利用するが、debian-slimにはルート証明書が含まれていないため、この通信が失敗していた。解決方法ca-certificateパッケージをインストールする。Dockerfileはこうなる。FROM golang:1.16 AS builderWORKDIR /srcCOPY go.mod go.sum ./RUN go mod downloadCOPY app ./appCOPY main.go ./RUN go build -ldflags="-w -s" -o myappFROM debian:10-slimRUN apt update && apt install -y ca-certificates   # 追記COPY --from=builder /src/myapp .EXPOSE 8080CMD [ "./myapp" ]

Post: "https://cognito-idp.ap-northeast-1.amazonaws.com/": x509: certificate signed by unknown authority" となるエラー

Twitterなどで散々言っていましたが、今年の1月〜7月号までの7回、技術評論社さんのSoftware Designに連載記事を寄稿していました。自分の中では今年上半期のビッグイベントだったので振り返ってみます。内容経緯感想連載は大変書きたい内容が書けたページ数オーバーしがち他の人が凄いお金の話おわりに謝辞内容「Rustで挑戦 ネットワークプログラミング」というテーマで、ネットワークのL3~L7の主要なプロトコル（IP, TCP, UDP, HTTPなど）を実装したり動かしたりしていました。各回の内容は以下にまとまっています。「Rustで挑戦ネットワークプログラミング」今月号で最終回です。前回実装したHTTPの続き、HTTP/2、QUICについて見ていきますスレッドに連載内容を簡単にまとめますhttps://t.co/IDLU42fG86 pic.twitter.com/vvC2vXsYCE— 電気ひつじ (@teru0x1) 2021年6月17日  経緯去年の9月ごろ、「Rustで始めるネットワークプログラミングの内容をもうちょっと易し目にしたテーマで連載を書きませんか？」というお誘いのメールが編集部の方から届きました。驚きはあったものの、自分はその頃大学院を休学していて時間もあったため、「じゃあやるか」ぐらいの気持ちで承諾するに至りました。感想連載は大変やはり単発の同人誌とは違って、毎月何かしらについて書く必要があるという点で連載は大変でした。さらに、必要な作業は次月の執筆だけではなく、提出済み原稿への編集部さんによるレイアウト・修正作業のレビューもあるため、月によってはかなりの時間を割いていました。一方で自分の書いたmarkdownが綺麗な文書になっていくのを眺めるのはとても楽しく、完成されたものや実際の雑誌を手に取ったときの感動は大きなものでした。Twitterなどで感想を書いてくださる方もいて嬉しかったですね（エゴサが捗ります）。書きたい内容が書けた内容に関してはほとんどこちら側に一任して頂けたので、自分が書いていて楽しく、読みたい内容を書くことができました。Rustネットワーク本をもっと易しくした内容で〜とのことでしたが、実際にはTCPを実装する難しい回などもあり、易しいとは？という気分になっていました（ごめんなさい）。ページ数オーバーしがち担当編集の方の話によると連載は基本6ページ、場合によっては8ページくらいまで伸ばせるとのことでした。「6ページも書くの大変だろうなぁ」と思っていたのですが、気がつけばほぼ毎回8ページ書いていました。このままだと10ページくらいになるので何とかしましょうみたいな月もあり、2回分に分割するなどしていい感じに対処して頂きました。図とかソースコードを入れると長くなるものですね。他の人が凄い同誌に寄稿している方々が業界の超有名人みたいな人が多く、目次を見ては毎月ビビっていました。お金の話なんかやたらと聞かれるので少しだけ書いておきますが、ページを書くと固定の原稿料が頂けるという感じです。雑誌の売上と報酬が連動することは（自分は）無かったです。副業に良いねーみたいな話をされることもありますが、正確で面白い記事を書く手間と時間を考えると、普通にエンジニアとして働いた方がお金の面だけでは良いと思っています。おわりにまだ就職して間もないのでしばらく執筆は控えめにしようかと思っています（ほんまか？）。今の仕事に慣れてきたらまた執筆関係の活動もやっていきたいですね。謝辞GitHubで毎回的確なレビューをして頂いた担当編集者の方、また割と無茶振りしてレビューをお願いしていた後輩のayumin君には感謝申し上げます。ありがとうございました。

Software Design誌に約半年間連載を書いていました

結論www.blacksheep.link    IN    A    13.231.154.170のようなレコードを権威サーバに設定したとする。1: まず、権威サーバに正しく設定できているか確認する。$ dig +norec @<name_server> www.blacksheep.link; <<>> DiG 9.10.6 <<>> +norec @ns-644.awsdns-16.net. www.blacksheep.link; (2 servers found);; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47564;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1  # ①;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096;; QUESTION SECTION:;www.blacksheep.link.       IN  A;; ANSWER SECTION:www.blacksheep.link.    30  IN  A   13.231.154.170 # ②...(omitted)①でflagsにaa(Authoritative Answer)があることを確認。これがあれば権威サーバからの回答である。②のAnswer Sectionで正しく設定できているか確認する。2: フルリゾルバからの応答を確認する。$ dig www.blacksheep.link; <<>> DiG 9.10.6 <<>> www.blacksheep.link;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13333;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 512;; QUESTION SECTION:;www.blacksheep.link.       IN  A;; ANSWER SECTION:www.blacksheep.link.    29  IN  A   13.231.154.170...(omitted)解説DNSにはスタブリゾルバ（DNSクライアント）、フルリゾルバ（問合せ代行兼キャッシュサーバ）、権威サーバ（レコードを登録するサーバ）の3つの構成要素が登場する。スタブリゾルバが問い合わせを行う際は、通常フルリゾルバに対して名前解決要求（再起的問い合わせ）を送信し、それを受けたフルリゾルバが権威サーバに問い合わせを行う（非再帰的問い合わせ又は反復問い合わせ）。[スタブリゾルバ]--->[フルリゾルバ] --->[権威サーバ(複数存在し階層構造になっている)]フルリゾルバは権威サーバから受けた結果を一定期間キャッシュするため、次にスタブリゾルバから問い合わせを受けた際にそのキャッシュを返すことができる。このキャッシュはクエリに対する結果が紐づいている物だけでなく、クエリに対応する結果が見つからなかった場合もキャッシュを行う（ネガティブキャッシュ）。そのため、DNSレコードを追加した際はまずスタブリゾルバから権威サーバに問い合わせを行い、設定が正しく行われているかを確認する。その後で、フルリゾルバを使った確認を行う。最初からフルリゾルバを経由した問い合わせを行ってしまうと、もしなんらかの理由で権威サーバに設定が正しく行われていない場合、ネガティブキャッシュがフルリゾルバに残ってしまう。ネガティブキャッシュが残っている以上、正しく権威サーバを設定し直した後も一定期間は空の結果が返ってきてしまう*1。コマンドスタブリゾルバから直接権威サーバに問い合わせるには次のようにする。digはデフォルトでフルリソルバへの問い合わせを想定した再帰的問い合わせを行うため+norecを指定することで無効にしている。$ dig +norec @<name_server> <target_domain>ネガティブキャッシュについてネガティブキャッシュに対するTTLはmin(SOAレコードのMINIMUMフィールドの値, SOAレコード自身のTTL)で決定される。AWS route53の場合、SOAレコードのMINIMUMフィールドの値が86400, SOAレコード自身のTTLが900だったので、ネガティブキャッシュは900秒間有効になる。*1:いわゆる、「DNSが浸透しない」と言われるもの

DNSレコードを設定した後の確認

codebuildでterraform initをした時に下記のようなエラーが出力されて落ちたInitializing provider plugins...- Reusing previous version of hashicorp/aws from the dependency lock file- Installing hashicorp/aws v3.42.0...Error: Failed to install providerError while installing hashicorp/aws v3.42.0: the current package forregistry.terraform.io/hashicorp/aws 3.42.0 doesn't match any of the checksumspreviously recorded in the dependency lock fileメッセージを読むと、どうやらリポジトリの.terraform.lock.hclに含まれているproviderのハッシュ値が一致しないことが原因となっている模様。.terraform.hcl.lock依存しているproviderとそのバージョンを固定するlockファイルであり、Terraform0.14から導入された。多くの言語に備わっているpackage.lockなどの仕組みと似ている。terraform initを実行した際、.terraform.hcl.lockに.tfで宣言しているproviderの記述がなければバージョン制約に基づいて最新のものを取得した後、その情報をlockファイルに書き込む。記述があればそれと同じバージョンを取得する。この時同時にlockファイルのproviderに付随しているチェックサムをもとに、initで取得したproviderと一致するかの検証が行われ、*1検証が失敗するとinitは失敗する。原因ローカルでterraform initした時に記述された.terraform.hcl.lockに含まれるproviderのチェックサムが、CI上でinitした時に取得・計算されたproviderのチェックサムと一致しなかったことが原因。ローカルとリモートでOSなどのプラットフォームが異なっていたり、ローカルでProvider Plugin Cache*2を使っている場合にチェックサムの不一致が生じてしまう。対処terraform providers lockというコマンドを利用することで事前に複数のプラットフォーム向けにチェックサムを生成し、.terraform.hcl.lockを生成することができる。例えば、ローカルのmacOSとCI上のLinuxでinitを実行する場合、ローカルで次のコマンドを実行することで.terraform.hcl.lockを生成する。$ terraform providers lock \  -platform=darwin_amd64 \  # 64-bit macOS  -platform=linux_amd64     # 64-bit Linux参考実際にはもっと複雑な事情があるらしい。 speakerdeck.comwww.terraform.iowww.terraform.io*1:SSHのknown_hostsの仕組みと同じくtrust on first useを採用している*2:https://www.terraform.io/docs/cli/config/config-file.html#provider-plugin-cache

【Terraform】CIでinitした時にdoesn't match any of the checksums previously recorded in the dependency lock fileとなる

ログデータにはある種の鮮度のようなものがあります。一般的に1年前のログと2日前のログだと、おそらく後者の方が取り出される頻度も重要度も大きいため、より早く、確実に取得したいと考えるでしょう。そのため、これらのデータを同様のストレージに同様の構成で格納しておくのはコスト面であまり良いとは言えません。1年前のログに対して3日前のログと同様の取得速度と信頼性を求めない場合、より安価なストレージに移動させる、あるいはレプリカ数を減らすなどといった変更を行うことで、インフラのコストを削減することが可能になります。Elasticsearchにはこのように自動的にインデックスのライフサイクルを管理し、設定を変更する機能が備わっています。本稿ではAWS Elasticsearch Service（AES）について述べます。AESで利用できるインデックスライフサイクル管理機能にはISMという名前がついています。ISM設定インデックスへの適応ISMISM（Index State Management）を利用することで、時間経過、インデックスのサイズ変化などのイベントをトリガーとしてインデックスの状態を変化させるアクションを実行することが可能です。アクションには、レプリカ数の変化、削除、Index Rollupの実行などを選択できます。Index Rollupとは、インデックスのあるフィールドだけ抽出したり、より粗い粒度で集約をかけたりすることで、インデックスのサイズを削減する機能のことです。設定ISMはKibanaコンソールか、ISM APIにISMポリシーをPUTすることで作成します。ここではAPIを利用する方法について解説します。次にism_sample.jsonを示します。このISMポリシーは7日後にレプリカ数を0に変更し、30日後にインデックスを削除するような処理を行います。{  "policy": {    "description": "sample",    "default_state": "current",    "states": [      {        "name": "current",        "actions": [],        "transitions": [          {            "state_name": "old",            "conditions": {              "min_index_age": "7d"            }          }        ]      },      {        "name": "old",        "actions": [          {            "replica_count": {              "number_of_replicas": 0            }          }        ],        "transitions": [          {            "state_name": "delete",            "conditions": {              "min_index_age": "30d"            }          }        ]      },      {        "name": "delete",        "actions": [          {            "delete": {}          }        ],        "transitions": []      }    ]  }}このJSONをPUTします。$ism_idは適当に設定しておきます。$ curl -XPUT -H 'Content-Type: application/json' -H "kbn-xsrf: true" "$ES_URL/_opendistro/_ism/policies/$ism_id" -d @ism_sample.jsonまた、AWS ESではインデックスをUltraWarmというストレージへ移動させるようなアクション(warm_migration)を設定することができます。Ultrawarmは大量のデータがある場合にはストレージにかかる費用を削減できるとありますが、数GiBくらいのデータの場合使うと逆に高くつくので注意が必要です。{    "name": "warm",    "actions": [{        "warm_migration": {}    }],    "transitions": []}インデックスへの適応作成したポリシーはインデックスにアタッチすることで適応されますが、これにはインデックステンプレートを利用するのが便利です。インデックステンプレートはインデックスのパターンと、それにマッチするインデックスに適応したい設定（マッピング定義、シャード数、ISM設定など）を記述することができます。なお、これらの設定はインデックスが新たに作成されるタイミングで適応されるため、すでに作成されているインデックスに対しては適応されません。次のようなtemplate.jsonで設定します。時系列データはインデックスに日付などの時間を含めるのがベストプラクティスとされていますが、それに従うと次のように未来に作成されるインデックスに対して設定の適応が可能になります。(例えば、my_log_2021-03-31など){  "index_patterns": [    "my_log_*"  ],  "settings": {    "opendistro.index_state_management.policy_id": "$ism_id"  }}curl -XPUT -H 'Content-Type: application/json' -H "kbn-xsrf: true" "$ES_URI/_template/$template_id" -d @template.json

【Elasticsearch】時間経過でインデックスを削除・設定変更

ターミナルに文字を出力する際に$ echo -e "\033[<パラメータ>m <表示する文字> \033[0m"とすることでパラメータに応じた文字色、背景色をつけることができる。パラメータは;で区切ることで複数種類指定することが可能。色の対応文字色は30~37、背景色は40~47までの値を指定する。次の擬似言語を実行したら画像のように色付けがされるtcolor <- range 30 37    bcolor <- range 40 47        echo -e "\033[${tcolor};${bcolor}m text:$tcolor background: $bcolor \033[0m"    donedone色の対応表

シェル色付け対応早見表

CircleCIでnodeアプリケーションのイメージをビルドしている時にエラーが出てfailした時の対処法メモエラー内容Dockerfile中のyarn installのステップで次の様なエラーを吐いて落ちた。error An unexpected error occurred: "EPERM: operation not permitted, copyfile '/usr/local/share/.cache/yarn/v6/npm-@babel-code-frame-7.10.4-168da1a36e90da68ae8d49c0f1b48c7c6249213a-integrity/node_modules/@babel/code-frame/LICENSE' -> '/app/node_modules/@babel/code-frame/LICENSE'".権限がどうこう言ってる。ローカルだとビルドが成功するので、環境の差異によるものだと思われる。解決策.circleci/config.ymlで利用するdockerのバージョンを指定する。ドキュメントにある通りバージョンを指定しないとdockerの17.09が使われてしまうようで、これだとnodeのビルドに失敗する。- setup_remote_docker:          version: 19.03.13参考support.circleci.com

CircleCIでyarn installした時に出る"EPERM: operation not permitted, copyfile ~"みたいなエラー

この記事についてgolangのechoが吐き出すログをvectorで収集し、opendistro版 Elasticsearchに収集、可視化する方法についてメモこの記事についてvectorについてopendistro Elasticsearchについてelasticsearch + kibanaの構築vectorの作成アプリケーションからのログ送信kibanaでの確認と可視化終わりにvectorについてvector.devRust製のデータ収集、変換ツールです。この分野で有名なものにtd-agent(fluentd)がありますが、vectorは高パフォーマンス、軽量を売りにしています。https://vector.dev/docs/about/what-is-vector/ より引用opendistro Elasticsearchについてopendistro.github.ioOSSのElasticsearchにいろいろなプラグインを同包したものです。elastic版Elasticsearchとは異なり、elastic社が有料プランで提供しているアラートなどの機能を無料で使うことができます。elasticsearch + kibanaの構築docker-composeを利用して構築します。無駄にクラスタを組んでますが1ノードでも問題なく動きます。docker-compose.ymlversion: "3"services:  server:    build: ./server    ports:      - 8888:8888  odfe-node1:    image: amazon/opendistro-for-elasticsearch:1.12.0    container_name: odfe-node1    environment:      - cluster.name=odfe-cluster      - node.name=odfe-node1      - discovery.seed_hosts=odfe-node1,odfe-node2      - cluster.initial_master_nodes=odfe-node1,odfe-node2      - bootstrap.memory_lock=true # along with the memlock settings below, disables swapping      - opendistro_security.disabled=true      - "ES_JAVA_OPTS=-Xms512m -Xmx512m" # minimum and maximum Java heap size, recommend setting both to 50% of system RAM    ulimits:      memlock:        soft: -1        hard: -1      nofile:        soft: 65536 # maximum number of open files for the Elasticsearch user, set to at least 65536 on modern systems        hard: 65536    volumes:      - odfe-data1:/usr/share/elasticsearch/data    ports:      - 9200:9200      - 9600:9600 # required for Performance Analyzer    networks:      - odfe-net  odfe-node2:    image: amazon/opendistro-for-elasticsearch:1.12.0    container_name: odfe-node2    environment:      - cluster.name=odfe-cluster      - node.name=odfe-node2      - discovery.seed_hosts=odfe-node1,odfe-node2      - cluster.initial_master_nodes=odfe-node1,odfe-node2      - bootstrap.memory_lock=true      - opendistro_security.disabled=true      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"    ulimits:      memlock:        soft: -1        hard: -1      nofile:        soft: 65536        hard: 65536    volumes:      - odfe-data2:/usr/share/elasticsearch/data    networks:      - odfe-net  kibana:    build: ./kibana    container_name: odfe-kibana    ports:      - 5601:5601    environment:      ELASTICSEARCH_URL: http://odfe-node1:9200      ELASTICSEARCH_HOSTS: http://odfe-node1:9200    networks:      - odfe-netvolumes:  odfe-data1:  odfe-data2:networks:  odfe-net:elasticsearchのセキュリティ機能をオフにしたので、kibanaのセキュリティプラグインも削除します。kibana/DockerfileFROM amazon/opendistro-for-elasticsearch-kibana:1.12.0RUN /usr/share/kibana/bin/kibana-plugin remove opendistroSecurityKibanaCOPY --chown=kibana:kibana kibana.yml /usr/share/kibana/config/kibana/kibama.ymlserver.name: kibanaserver.host: "0"./serverにはechoアプリケーションが入ります。開発環境なのでfreshでオートビルドされるようにしてあります。./server/DockerfileFROM golang:1.15.6-alpine3.12WORKDIR /go/src/appRUN apk add --no-cache \    alpine-sdk \    git \    && go get github.com/pilu/freshCMD [ "fresh" ]ビルドしていい感じにkibanaにログインできたらOKvectorの作成こちらもDockerで立てます。ネットワークはアプリケーションがあるdefaultとelasticsearchがあるodfe-netの両方に属している必要があります。docker-compose.yml  vector-server:    image: timberio/vector:0.11.X-alpine    volumes:      - ./vector/vector.toml:/etc/vector/vector.toml:ro    depends_on:      - odfe-node1    networks:      - default      - odfe-netvectorでは次の3つを指定します。sources: データの発生元transforms: sourcesで受け取ったデータの変換規則（オプション）sinks: 最終的なデータの受け渡し先sourcesではファイルやOSのメトリックの他、サーバを立ててそこに投げられるデータを扱うことも可能です。今回はsocket sourceを利用してechoアプリケーションのログをUDPで受けるようにします。https://vector.dev/docs/reference/sources/socket/#outputにあるように、socket sourceで受けたデータはmessageフィールドにコンテンツが格納されるので、transformsでそれを抽出し、elasticsearch sinkに渡します。./vector/vector.toml[sources.origin]  type = "socket" # required  address = "0.0.0.0:50000" # required, required when mode = `tcp` or `udp`  mode = "udp" # required[transforms.extract_message]  type = "json_parser" # required  inputs = ["origin"] # required  field = "message" # optional, default[sinks.elastic]  type = "elasticsearch" # required  inputs = ["extract_message"] # required  endpoint = "http://odfe-node1:9200" # required  index = "echo-log-%F" # optional, defaultアプリケーションからのログ送信echoにはロギング用のミドルウェアが備わっているのでそれを使い、UDPのエンドポイントとstdoutに同時に出力するようにしています。$VECTOR_SERVERには先ほどvector.tomlのsocket sourceで指定したアドレスがセットされるようにする必要があります（省略）。main.goe := echo.New()api := e.Group("/api")var output io.Writer = os.Stdoutraddr, err := net.ResolveUDPAddr("udp", os.Getenv("VECTOR_SERVER"))if err == nil {    conn, err := net.DialUDP("udp", nil, raddr)    if err == nil {        output = io.MultiWriter(output, conn)    }}api.Use(middleware.LoggerWithConfig(middleware.LoggerConfig{    Output: output,}))ここまでできれば、アプリケーションのログがvectorを通してelasticsearchに蓄積されるようになります。$ curl localhost:9200/_cat/indices?vhealth status index                           uuid                   pri rep docs.count docs.deleted store.size pri.store.sizegreen  open   echo-log-2021-01-17             i8CpjKbuSAGEX3J5Ez6dmg   1   1          5            0     27.5kb         13.7kbkibanaでの確認と可視化ログインし、右のメニューからStack Management > Index Patterns > Newを選択しecho-log-*でインデックスパターンを作成します。これでVisualizationが利用できます。Visualizeタブからグラフを作成しました。BucketsがX軸、MetricsがY軸になります。X軸方向にはタイムスタンプによる時間、Y軸にはログのカウントを取っています。ログのフィールドからHTTPのステータスコードやレスポンスタイムを可視化することも可能です。終わりにgolang echo + vector + elasticsearch + kibanaによるログ可視化について記述しました。ログが収集できたので、この値を元にアラートを飛ばすことも可能です（これが無料でできるのがopendistro版ESの良いところ）。次回はアラートについて書きたいと思います。

vectorでelasticsearchにEchoのログを収集してみる

どんな本か最終的に出来上がるもの対象読者について各章について1章2章3章4章頒布先リンク書籍で解説しているソースコードおわりにどんな本かRustを使い，「TCPセグメントが1つ送信できる」という段階から「自作TCPを使って画像ファイルを送信できる」という段階まで少しずつTCPの実装を作成していく本です．「Rustで始めるTCP自作入門」を技術書典10で販売しています！RustでTCP実装を作り，エコーサーバやファイルアップローダをその上で動かします．Rustで何か作りたい人，TCPの入門書を読んで中身が気になった人はどうぞ！拡散していただけると喜びます！ #技術書典 https://t.co/zOlDxBTTya pic.twitter.com/9Ln3VTWR1b— 電気ひつじ@技術書典10/Rustで始めるTCP自作入門 (@teru0x1) December 27, 2020 最終的に出来上がるもの自作TCPの上で次のアプリケーションが動くことを目標にしています．エコーサーバ，エコークライアント文字列のやりとりを行うサーバは複数のクライアントを同時にハンドリングするファイルサーバ，クライアントアップロード機能のみクライアントから数MBのファイルをサーバにアップロードする少しくらいパケットがロスしても問題なく完了するこれらのアプリケーションを作るにあたって，自作TCPにおいて作成する機能は主に次の通りです．listen, accept, connect, send, recv, closeといった基本的なAPI再送制御順序制御スライディングウィンドウ対象読者についてRustの基本的な文法を知っている人("The Rust Programming Language(https://doc.rust-jp.rs/book-ja/)"の内容が大体わかる)TCP/IPの基本的な知識がある，またはいつでも参照できるよう入門書（マスタリングTCP/IPなど）が手元にある人Linux開発環境が用意できて，それ関する基本的な知識（コマンド操作など）がある人ネットワークプログラミングに興味のある人Rustで何か作ってみたい人となっています．Rustの文法そのものに関する説明は本書には無いので，基本的な文法は抑えてから読むのをお勧めします．それほど高度な文法は使われていないため，リファレンスがあれば読み進めるには問題ないと思います．やや難解なところは都度解説を入れています．ネットワークソフトウェアやTCPそのものに関する解説も少ししか登場しません．「コネクション」，「確認応答」といった用語は知ってる前提として，「それらをどうプログラムとして表現するか」という部分に重きをおいて解説しています．各章について1章1章は基礎編です．std::netにあるTCPのソケットを使ってエコーサーバを作り，アプリケーションからTCPの挙動を観察します．この観察を元に，TCP実装に必要となりそうな要素を考えてきます．また，生ソケットといった実装に必要な知識についても紹介しています．2章2章は準備編です．LinuxのNetwork Namespaceを利用して，TCP実装に用いる環境の構築を行います．3章3章がメインとなる実装編です．小さなTCPセグメントを送信するところから始まり，スリーウェイハンドシェイク，送信，受信，切断の機能を徐々に追加していきます．最終的には，少しのパケットロスが生じる環境下で画像ファイルを送信することができるようになります．4章4章は振り返り編です．3章で作った実装を眺めながら，TCPのパフォーマンスに影響を与える要素や仕様が持つ問題点，及びそれを解決すべく生まれたQUICプロトコルについて解説します．頒布先リンクtechbookfest.org書籍で解説しているソースコードソースコードは環境構築スクリプトと共に公開しています．どんなものが出来上がるのか知りたいという方は下記リンクからどうぞ．github.comおわりに現時点で200部ほど買って頂いています（ありがとうございます）．買ってくださった方は感想・作ってみた・批判・高評価・低評価などを呟くなりブログに書くなりして頂けると励みになるのでよろしくお願い致します！

技術書典10で「Rustで始めるTCP自作入門」を頒布してます

この記事は，HUITアドベントカレンダー2020の20日目の記事です．一昨年はスクリプト言語「Sheep」を作ってみた - Qiitaを書きました．去年は卒論で戦死してたのでアドカレがあったのかどうかも知らないです（）．brainf*ckとはja.wikipedia.org難読プログラミング言語の1つです．書いていると気が狂ってくるのでこのような名前になっています．可読性は最悪ですがチューリング完全な言語なので，巷にあるプログラミング言語で行える処理はbrainf*ckでも可能になっています．命令内容はたったの8つです．トークン説明  >  ポインタをインクリメントする <  ポインタをデクリメントする +  ポインタの指す値をインクリメントする -  ポインタの指す値をデクリメントする .ポインタが指す値を出力に書き出す ,入力から1バイト読んで、ポインタが指す先に代入する [ポインタが指す値が0なら、対応する ] の直後にジャンプする]ポインタが指す値が0でないなら、対応する [ の直後にジャンプするソースコード言語処理系の実装に向いていると言われているRustで実装していきます．単純な言語なので一般的なプログラミング言語のようにイテレータをpeek()して分岐したりパースしたりする必要はありません．use anyhow::Result;use std::io::{self, prelude::*};const BUFFER_SIZE: usize = 30000;fn main() -> Result<()> {    loop {        let mut input = String::new();        io::stdin().read_line(&mut input)?;        let input_chars: Vec<char> = input.chars().collect();        exec(&input_chars)?;        print!("\n");    }}fn exec(input: &[char]) -> Result<()> {    let mut buffer = [0; BUFFER_SIZE];    let mut buffer_ptr = 0;    let mut input_ptr = 0;    let mut prev_paren = Vec::new();    while input_ptr < input.len() {        match input[input_ptr] {            '>' => {                buffer_ptr += 1;            }            '<' => {                buffer_ptr -= 1;            }            '+' => {                buffer[buffer_ptr] += 1;            }            '-' => {                buffer[buffer_ptr] -= 1;            }            '.' => {                print!("{}", char::from(buffer[buffer_ptr]));            }            ',' => {                buffer[buffer_ptr] = io::stdin().bytes().next().and_then(|r| r.ok()).unwrap();            }            '[' => match buffer[buffer_ptr] {                0 => {                    while input_ptr < input.len() && input[input_ptr] == ']' {                        input_ptr += 1;                    }                }                _ => prev_paren.push(input_ptr),            },            ']' => match buffer[buffer_ptr] {                0 => {                    prev_paren.pop().ok_or(anyhow::anyhow!("invalid ]"))?;                }                _ => {                    if prev_paren.len() <= 0 {                        anyhow::bail!("no previous paren")                    }                    input_ptr = prev_paren[prev_paren.len() - 1];                }            },            _ => {}        }        input_ptr += 1;    }    Ok(())}$ cargo run    Finished dev [unoptimized + debuginfo] target(s) in 0.01s     Running `target/debug/brainfuck`++++++++++[>++++++++++<-]>++.+++++++++..fooぱっと見だと意味が分からないですがascii文字でf,o,oを出力しています．最初に10個バッファに加算しているのはループ用の変数です．1つ右にポインタをずらしてf用の値をループしながらひたすら加算して作成します．+[>,.<]hitsujihitsujiこれはエコーサーバーです．コンパクトですね．バッファを行ったり来たりしながら文字を出力しています．おわりにbrainf*ckでbrainf*ckインタプリタの実装をする猛者もいるようです．http://esoteric.sange.fi/brainfuck/bf-source/prog/BFI.BF世の中は広いですね．

Rustでbrainf*ckインタプリタ作ってみた

このエントリは，Rust 3 Advent Calendar 2020の8日目の記事です．はじめにエラー処理の基本Result<T, E>Errorトレイト?オペレータベストプラクティスを支えるクレートanyhowthiserrorfailureクレートについてまとめ追記はじめにRustを書いている時にアプリケーション固有のエラー型を定義したい場合があります．この辺のベストプラクティスは今まで何度か変化*1しており，今年の9月にエラーハンドリングのプロジェクトグループが発足*2したことからも分かるとおり，今後も変化していく可能性が濃厚です．この記事では，エラー処理まわりに関する基本的な内容と，現時点でのベストプラクティスとされているanyhowとthiserrorを用いたエラー処理について紹介します．エラー処理の基本Result<T, E>Rustには例外がなく，失敗するかもしれない関数は戻り値としてstd::result::Resultを返すことで呼び出し元にエラーを伝えます．std::result::Resultはenumとして定義されています．pub enum Result<T, E> {    Ok(T),    Err(E),}戻り値の型を指定することで，独自に定義したエラー型を返すことができます．次の例だと，MyErrorは独自に定義したenumであり，hoge()はResult<(), MyError>型を返しています．fn hoge() -> Result<(), MyError> {    // ...    return Err(MyError::HogeError(1));}enum MyError {    HogeError(u8),    FooError(String),}一方で，このような書き方をするとhoge()はResult<(), MyError>しか返すことができないため，複数種類のエラーを呼び出し元に返そうとした場合にコンパイルエラーとなります．例えば次のような場合です．fn hoge(filename: &str) -> Result<(), MyError> {    let f = File::open(filename)?; // エラーの場合Err(std::io::Error)が返る    // ...    return Err(MyError::HogeError(1)); // Err(MyError)が返る}コンパイラはこのコードを拒絶します．error[E0277]: `?` couldn't convert the error to `MyError`  --> src/main.rs:16:33   |15 | fn hoge(filename: &str) -> Result<(), MyError> {   |                            ------------------- expected `MyError` because of this16 |     let f = File::open(filename)?;   |                                 ^ the trait `std::convert::From<std::io::Error>` is not implemented for `MyError`   |   = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait   = note: required by `std::convert::From::from`コードの実行パスごとに返る型が一致していないためエラーになります．(エラーメッセージでFromがどうこう言っているのは後ほど触れます．)よって，戻り値にはトレイトを使い，関数内の全ての実行パスにおいて返されるエラー型がそのトレイトを実装するように変更します．このようにすることで，独自に実装したエラー型も含む複数種類のエラー型を1つの関数から返すことが可能になります．Errorトレイト標準ライブラリにstd::error::Errorトレイトが用意されているので，それを利用します．stdで定義されているエラー型（std::io::Errorやstd::num::ParseIntError）はこのトレイトを実装しているので，独自エラー型に対しても同様に実装します．std::error::Errorの定義は次のようになっています．pub trait Error: Debug + Display {    fn source(&self) -> Option<&(dyn Error + 'static)> { ... }    fn backtrace(&self) -> Option<&Backtrace> { ... }    fn description(&self) -> &str { ... }    fn cause(&self) -> Option<&dyn Error> { ... }}これらの4つのメソッドは全てデフォルト実装が存在するので，独自エラー型での実装は必須ではありません．さらに，backtraceはnightlyのみでの利用，descriptionとcauseは非推奨となっているので，stableチャネルで利用できるのは実質sourceメソッドのみとなっています．トレイト境界を満たすためにDebugとDisplayは実装が必要です．Debugはderiveできるのでそれを利用します．#[derive(Debug)]enum MyError {    HogeError(u8),    FooError(String),}impl Display for MyError {    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {        use self::MyError::*;        match self {            HogeError(i) => write!(f, "HogeError: {}", i),            FooError(s) => write!(f, "FooError: {}", s),        }    }}impl Error for MyError {}あとは関数の戻り値の型をResult<(), Box<dyn Error>>とする*3ことで，MyErrorをエラー型として返すことができます．（追記も参照）fn hoge(filename: &str) -> Result<(), Box<dyn Error>> {    let f = File::open(filename)?;                 // std::io::Errorを返す    // ...    Err(MyError::FooError("foo".to_string()))?;    // MyErrorを返す    // ...    Ok(())}?オペレータここで?オペレータについて補足しておきます．let a = val?;このように書いた場合，次のコードと等価です．let a = match val {    Ok(v) => v,    Err(e) => return Err(From::from(e))}オペランドがErrの時はErr(From::from(e))をリターンします．Fromトレイトのメソッドが呼ばれていますが，どの型に実装したfromが呼ばれるかは関数の戻り値に記述した型を元に推論されます．先ほどのhoge()の例で言うと，次の2つのコードは等価になります*4．Err(MyError::FooError("foo".to_string()))?;return Err(Box::<dyn Error>::from(MyError::FooError("foo".to_string())));ベストプラクティスを支えるクレート先ほどのエラー処理にはエラー発生時のコンテキストの情報が乏しいボイラープレートを記述するのがめんどくさいといった弱点があります．1つ目に関しては次のコードに対して実行結果を表示させてみます．fn main() -> Result<(), Box<dyn Error>> {    hoge("./hoge.txt")?;    Ok(())}fn hoge(filename: &str) -> Result<(), Box<dyn Error>> {    let f = File::open(filename)?;                 // std::io::Errorを返す    // ...    Err(MyError::FooError("foo".to_string()))?;    // MyErrorを返す    // ...    Ok(())}// MyError, Display, Errorの実装は同じ./hoge.txtが存在しない時は次のように出力されます．Os { code: 2, kind: NotFound, message: "No such file or directory" }あっさりとしています．どのファイルが見つからなかったのかみたいな情報を付与したさがあります．弱点の2つ目に関しても，独自エラー型に対するDisplayやErrorの実装は退屈であまり面白くはありません．これらの弱点はそれぞれanyhowとthiserrorクレートで手軽に解決することができます．anyhowhttps://github.com/dtolnay/anyhowanyhowはエラーにコンテキスト情報を含める便利メソッドや便利マクロ，エラー型などを提供するクレートです．anyhowを使ったコードは次のようになります．use anyhow::{Context, Result};fn hoge(filename: &str) -> Result<()> {    let f = File::open(filename).context(format!("failed to open file: {}", filename))?;    // ...    Err(MyError::FooError("foo".to_string()))?;    // ...    Ok(())}戻り値がanyhow::Result<()>になりました．この型はstd::result::Result<(), anyhow::Error>のエイリアスになっています．anyhow::ErrorはBox<dyn std::error::Error>とほぼ同じような役割を持つため，戻り値の型をこのように変更しても関数内部を変更しないといけないケースは多くありません．hoge()の1行目ではcontext()を使うことでエラーにコンテキスト情報を含めています．前節と同様に実行してみます．Finished dev [unoptimized + debuginfo] target(s) in 0.71s    Running `target/debug/my-error` failed to open file: ./hoge.tx  Caused by:     No such file or directory (os error 2)コンテキスト情報が含まれ，ややリッチなエラーメッセージが表示されるようになりました．contextと似たようなメソッドとしてwith_contextというのも用意されており，こちらはクロージャを渡すことでエラー発生時のみ文字列生成を行うことが可能です．エラーが起きなかった場合はformat!のコストを払う必要が無いということですね．let f = File::open(filename).with_context(|| format!("failed to open file: {}", filename))?;anyhowにはそのほかにもanyhow!やbail!などの便利マクロが備わっています．thiserrorhttps://github.com/dtolnay/thiserrorthiserrorはstd::error::Errorのためのderiveマクロを提供します．anyhowと作者が同じで，それと組み合わせて使うことも可能です．thiserrorを使ったコードは次のようになります．use anyhow::{Context, Result};use std::fs::File;use thiserror::Error;#[derive(Debug, Error)]enum MyError {    #[error("HogeError: {0}")]    HogeError(u8),    #[error("FooError: {0}")]    FooError(String),}fn hoge(filename: &str) -> Result<()> {    let f = File::open(filename).context(format!("failed to open file: {}", filename))?;    Err(MyError::FooError("foo".to_string()))?;    Ok(())}// Display, Errorの実装は不要になるMyErrorに対してderiveマクロのthiserror::Errorを使っています．また各エラー値に対しては，#[error(...)]を使うことでDisplayと同等の機能を実装しています．ここでは簡単なフォーマット記法を利用することが可能で，次のような変換規則があります．       マクロ                   展開             #[error("{var}")]    write!("{}", self.var)     #[error("{0}")]      write!("{}", self.0)    #[error("{var:?}")]  write!("{:?}", self.var)   #[error("{0:?}")]    write!("{:?}", self.0)  エラー値は#[error(transparent)]と#[from]を用いることで他のエラー型にDisplay相当の機能を委譲することもできます．#[derive(Debug, Error)]enum MyError {    #[error("HogeError: {0}")]    HogeError(u8),    #[error("FooError: {0}")]    FooError(String),    #[error(transparent)]    Other(#[from] anyhow::Error), // エラーのバリアントを追加}fn hoge(filename: &str) -> Result<()> {    let f = File::open(filename).context(format!("failed to open file: {}", filename))?;    Err(MyError::FooError("foo".to_string()))?;    Err(MyError::Other(anyhow::anyhow!("Other err")))?; // anyhow::Errorをラップしている    Ok(())}failureクレートについて少し前まではanyhowやthiserrorと同様のことを実現するためにfailureクレートが利用されていました．当時はstd::error::Errorトレイトの使い勝手があまり良くなかったため，独自にFailトレイトを導入し，関数の戻り値の型にはResult<T, failure::Error>を指定する，といったことが行われていました．現在ではfailureクレートの知見を元にstd::error::Errorトレイトに改善が加えられたため，本クレートは凍結状態となっています．failure公式はanyhowとthiserrorの使用を推奨しています．まとめ関数からエラーを返すとき，サードパーティークレートを使わないなら原則として戻り値の型にResult<T, Box<dyn Error>>を指定する（追記も参照）anyhowでエラー情報をリッチに，扱いやすくできるthiserrorで独自エラー型の定義が楽になるfailureクレートは次の世代に希望と知見を託して消えていった．現時点では非推奨なので気をつけよう追記@lo48576さんからご指摘をいただきました．戻り値の型はResult<T, Box<dyn Error + Send + Sync + 'static>>とした方がベターとのことです．このポストで使ってきたhoge()を例にとるとこのようになります．fn hoge() -> Result<(), Box<dyn Error + Send + Sync + 'static>> {    let f = File::open("./hoge.txt")?;    Err(MyError::FooError("foo".to_string()))?;    Ok(())}まずSendとSyncに関してですが，これらのトレイト境界を付与するとそれぞれ「他のスレッドに送信しても安全」，「他のスレッドと共有しても安全」という制約が付きます．マルチスレッドを用いたプログラミングをしている際に必要になります．例えば次のような呼び出しをした場合，Sendが無い場合コンパイルエラーになります．thread::spawn(|| hoge());SyncはSendと共に実装されることが多いです．'staticトレイト境界に関してはRustの2種類の 'static | 俺とお前とlaysakuraで詳しく解説してくださっています．これを付与しておくと，isやdowncast_refといったメソッド*5が利用できるようになり，呼び出し元で柔軟なエラーハンドリングが可能になります．例えば次のようなコードです．if let Err(error) = hoge() {    match error.downcast_ref::<MyError>().unwrap() {        MyError::HogeError(u) => println!("retry...: {}", u),        MyError::FooError(s) => println!("notify slack: {}", s),    }}@lo48576さん，ありがとうございました．*1:https://qiita.com/legokichi/items/d4819f7d464c0d2ce2b8*2:https://blog.rust-lang.org/inside-rust/2020/09/18/error-handling-wg-announcement.html*3:Boxに入れないと，コンパイル時にサイズが決定できないのでコンパイルできません*4:ドキュメントには，Boxに対するFromの実装が記載されています*5:https://doc.rust-lang.org/stable/std/error/trait.Error.html#method.is

Rust エラー処理2020

ハッシュがa6e0229のコミットは関係ない2ファイルを同時にコミットしており，これを1ファイルずつのコミットに分割したいとする．コミットログはこのようになっている．* 6eba8e2 (HEAD -> master) add README.md* a6e0229 add server* 9f80a28 update修正したいコミットの1つ前を指定してrebase -iする．$ git rebase -i 9f80a28エディタが開くpick a6e0229 add serverpick 6eba8e2 add README.md# Rebase 9f80a28..6eba8e2 onto 9f80a28 (2 commands)## Commands:# p, pick <commit> = use commit# r, reword <commit> = use commit, but edit the commit message# e, edit <commit> = use commit, but stop for amending# s, squash <commit> = use commit, but meld into previous commit....(omitted)変更したいコミットのハッシュがある行を次のように変更してエディタを終了させる．- pick a6e0229 add server+ edit a6e0229 add serverこの時点でのステータスはこんな感じ．先ほどpick→editに変更したコミットまで実行されている状態になっている模様．ここから分割をしていく．$ git statusinteractive rebase in progress; onto 9f80a28Last command done (1 command done):   edit a6e0229 add serverNext command to do (1 remaining command):   pick 6eba8e2 add README.md  (use "git rebase --edit-todo" to view and edit)You are currently editing a commit while rebasing branch 'master' on '9f80a28'.  (use "git commit --amend" to amend the current commit)  (use "git rebase --continue" once you are satisfied with your changes)nothing to commit, working tree cleanまずリセットを行いHEADとブランチが指すコミットを巻き戻す．インデックスもそのコミットで書き戻された状態になる．ワーキングディレクトリはそのまま．$ git reset HEAD^次に意図した通りに適切な粒度でコミットを行う．単純な分割であれば最終的に分割前のコミットが終わった時と同じ状態になっている．$ git add server.py$ git commit -m "add server"$ git add access.py$ git commit -m "add access"分割が終わればリベースを続行する．$ git rebase --continue最終的にコミットログはこのようになる．リベースで指定したコミットより後ろのコミットは全てハッシュが変わっている（分割に関与していないものも含めて）ため，すでにpushしている場合は気をつけるべき．* a0b6c70 (HEAD -> master) add README.md* aa5babd add access* fdc480d add server* 9f80a28 update

Gitでコミットを分割する

8~10月の間ずっとインターンやら何やらをしていて休みという休みがなかったので，3密に気を付けながらgotoしてきました．自分が5年後くらいに見返して懐かしむ用の記事なので内容は期待しないでください．前回↓cha-shu00.hatenablog.com通ったルート1日目2日目終わりに通ったルート東端から時計回り超雑にかくとこんな感じです．大田区の自宅から箱根まで行って一泊し，富士山をぐるっと回る形で帰ってきました．（赤いラインが内側にのめり込んでるあたりが箱根）1日目狙ったかのような快晴で，自宅近くの駅からでも富士山の山頂がはっきりと見えてました．近くだともっと見えるかもという期待を胸にとりあえず小田原へ．新幹線も止まる大きな駅ここから箱根登山鉄道という列車に乗ります．日本で一番（世界でも2番目）勾配のキツい坂がある路線だそうです．酷い写真ですがこれは先頭車両からの眺めで，トンネルの中にいる時のものです．目で見てわかるレベルの坂は電車にとっては急勾配らしい．トンネルが多い信号場で進行方向を変える．このようなスイッチバックを3回繰り返して山頂まで登っていく箱根登山鉄道の終点，強羅駅にあるこれは「手湯」らしいですが即死トラップなので触る時は覚悟しましょう．カップラーメン作れるレベルで熱かったです．測ってないけど軽く100℃は超えてると思う小田原→強羅（箱根登山鉄道）→早雲山（ケーブルカー）→桃源台（ロープウェイ）→芦ノ湖（遊覧船）が箱根ガン決まりルートらしいですが，寒かったのと曇ってたので*1船には乗りませんでした．晴れてれば湖上から富士山がきれいに見えるようです．ロープウェイの上から見える火山と硫黄行ってみて初めて知ったのですが，桃源台のある芦ノ湖は第3新東京市としてエヴァに登場します．町おこしコラボをやっていました．新劇場版が来年1月公開です！！！！！！！！！！！！セントラルドグマ（遊覧船チケット販売所）に通じているススキが無限に群生している場所（仙石原すすき草原）を経由して宿に向かいます．今回は前回のような民宿ではなくKKR宮ノ下という旅館を利用しました．美味しい料理と温泉で下がりきったHP/MPを全快させます．海だべがと おら おもたれば やっぱり光る山だたじゃい（宮沢賢治 「高原」*2）あわび初めて食べた良い部屋．自宅の1Rに帰る気が全て失せた．https://www.kkr.or.jp/hotel/list/miyanosita/2日目2日目は富士山を車窓から見ることがミッションです．小さい時に家族と富士観光した事があるのですが，曇天で1ミリも見えずとても悔しかった記憶があります．果たして今回は・・・？／^o^＼ﾌｯｼﾞｯｻｰﾝ見えました！！写真だと見慣れてると思うのですが生の富士はやっぱり迫力が違いました．機会あればもっとふもとで見たいですねー．この時乗ったのは富士山の西側を南北に縦断している身延線です．富士山の見える区間と富士川の見える区間があり，自然をたっぷりと味わえる良い路線でした．途中下部温泉といういかにも温泉に入れそうな駅があったので下車しました．「しもべ」温泉駅と読む．駅員はいない芦ノ湖に続いてここも来てみて初めて知ったのですが，「へやキャン」の聖地らしいです．左：店に展示されていた「へやキャン」8話のシーン．右：下部温泉駅前非常に趣のある温泉街でしたが，廃業や無期休業となっている宿屋も多くありました．廃業したものも含めて宿屋の数がとても多く，かつては賑わっていた事が想像できます*3．温泉街とは思えないほど川の水が綺麗だったこの通りには宿屋が密集していた通りから外れたところにある小さな社の脇に山道らしきものがありました．クマが出てきたら嫌なので絶対行かないぞと思ったのですが，道標にある「大すべり台」が気になりすぎてつい進んでしまいました・・・手入れはされてなさそうだなんと，本当に滑り台がありました．脇には劣化して壊れたソリが捨てられてあります．遊ぶ子供はいない「グリーンジャンボ」の宝くじ感は異常せっかくなので登ってみました．それなりの高さがあるいや結構高いな！そりで降りるにしてもかなりのスピードが出そう．かつてはここで遊ぶ街の子供たち，もしくは観光客の家族がいたのでしょうか．今ではその影はどこにも見当たりません．相当奥まった場所にあるため，今となっては地元の人以外に知られることはないでしょう．昔のこの街の姿を自分だけが一部垣間見る事ができた気がして，謎の優越感に包まれていました．と思ったら意外と最近の観光客にも知られていることをさっき知りました．【下部温泉の大すべり台・グリーンジャンボ】山の中に出現！よく滑るスリリングなすべり台で遊ぼう│やまなしファンぬる湯の下部温泉④スリルの大すべり台 | うさぎくらぶそこそこ有名みたいですねはいそんな感じで下部温泉を後にして甲府でほうとう食べて大田区に帰りました．おしまい．*4初めてのほうとう．太い味噌煮込みうどんと言ってはいけない終わりに東京に越してきてから初めての旅行でした．ここでは自宅から電車を2時間くらい乗っても札幌駅から電車で15分くらいの光景がずっと続きます*5．東京都市圏の巨大さを実感した旅でした．下部温泉で買ったおみやげ*1:午前中はよく晴れてたんだけどね・・・山の天気は変わりやすい・・・*2:本ポストの教養マウントその1である．ススキの穂が日光に反射して銀色に輝き，海のように見える光景を詩にしている．晴れていれば海のように見えるんだろうかと小学生の時に教科書で見たこの一説を思い出していた．*3:私の来た時期が悪かっただけで，現在も実は賑わっていたらごめんなさい*4:書くのがめんどくさくなったのではなく，実際食事以外何もしてない上に電車も普通なので語れる事がない*5:見てもあまり面白くない住宅街がずっと続く，ということ

onoteru