もうずっといなかぐらし

かたいなかのブログ

なぜ、ゆるSRE勉強会をやりたいと思ったのか

こんにちは、かたいなかです。

おかげさまで、ゆるSRE勉強会は好評を頂いており、2/22に4回目の開催を迎えることとなりました。

yuru-sre.connpass.com

これは、ひとえにイベントを盛り上げていただいている参加者の方や、開催場所等で協力いただいているスポンサー企業の皆様あってのことと思っております。 本当にありがとうございます。

ゆるSRE勉強会の開催に至った経緯や、これからの展望について盛り上がっているうちに記事してしまおうと思い、この記事を書き始めました。

ゆるSRE勉強会とは

『ゆるSRE勉強会』は、ゆるい雰囲気で肩肘張らずにSRE関連のトピックについて話そう！という趣旨の勉強会です。

yuru-sre.connpass.com

この勉強会で、最近SREになったばかりの方からベテランSREの方まで、様々な方がSRE関連の話題について肩肘張らずに共有できる場を作れればと考えています。

昨年の8月から2ヶ月の一回のペースで開催しており、2/22に4回目の開催を迎えることとなりました。

開催したいと思った理由

このような勉強会を開催したいと思ったのは、以下の2つの個人的な経験からでした。

SREとしてエンジニアを続けていく中で、あまり外向けに発表しづらい泥臭いことばかりやる期間がある

SREとして働いている中でレガシーシステムを地道に改善していく時期等がありました。そのような時期には、なかなか外向けに発表しやすいような"キレイな"成果を出しにくいと感じていました。例えば、レガシーすぎる内容を外向けに出してしまうと、採用にも差し障るだろうしなぁと外向けの発表に二の足を踏んでしまったりしました。

一方で、会社の評価基準には、外部へのアウトプットも求められたりすることもあり、難しさを感じてしまう事が多くありました。

このようなことは友人のエンジニアとの会話でも度々話題に登っていたため、キレイでない泥臭い改善を共有したりしやすい場にメリットを感じてくれる人はたくさんいるのではないかなと思っていました。

フォーマルな雰囲気の大きな勉強会への踏み台となるような勉強会があまりない

こちらについては、会社の記事でも詳しく説明しています。

made.livesense.co.jp

以前から会社での採用広報の仕事の中で、社内メンバーの外部登壇を促進したいと考えており、色々施策をやったのですがうまくいかず悩んでいました。社内LT大会は大盛況なのに外部の勉強会にはあまり足が伸びない現象があり、これはなぜだろうと考えていました。

仮説として、会社のメンバーが運営をやっていたりする、半分身内の雰囲気の勉強会があれば、外にいきなり出ていくハードルが下げられるのではないかと考えていました。 *1

また、とくにSREの領域ではゆるい雰囲気の勉強会がコロナの関係で減ってしまい、まだ復活してきていないなぁと感じていました。そのため、ゆるい雰囲気の勉強会を提供できれば、同僚以外の方にも大きい価値のあるイベントができるのではないかと感じていました。

ただ、開催した勉強会が盛り上がらなかったらどうしよう・・・など考えてしまい、しばらく二の足を踏んでいました。

開催に向けて

ツイート

上記のような理由もあり、開催したいとぼんやりと思っていた中、なんとなくそのような勉強会についてツイートしてみたところ*2、反応もある程度もらうことができました。

自分たち以外にも似た問題を持っていることを確信し、そのような勉強会を開催にむけて動き出すことにしました。

勉強会の設計

個人的に勉強会の開催に知見がたくさんあるわけではなかったため、しょっさん（@syossan27）とずんだまるさん（@zuncha318）のお力をお借りし、開催に向けて進んでいくこととしました。

運営で認識合わせのためのブレストを行い、以下のような方向性を決めました。

  • 和気あいあいとした雰囲気を作る
  • オフライン開催で初発表者が発表しやすい雰囲気を作ること
  • 大きい勉強会への踏み台にしてもらうことを大歓迎
  • 会社のイベントではなくコミュニティイベントとして開催

初回開催とその後

初回の時点では、まだ考慮が及んでおらず不十分な準備となってしまう部分もありましたが、発表者の方の興味を惹かれる内容での発表もあり、大盛況となりました！

togetter.com

その後も、初登壇をゆるSRE勉強会でしてくれる方々（みなさん初登壇なのに内容がちゃんとしている、それでいて初登壇ならではの勢いがある！）や、地方から参加してくれている方がいたりなど様々な属性の方に参加いただけているのが、運営メンバーとしてとても嬉しい気持ちです。

最近では、登壇者の方が「ゆる」の意味をうまく解釈した面白い発表してくれたりなど、アンケートや懇親会等で会の運営について建設的な提案をしてくださる方もいらっしゃったりして、コミュニティとして勉強会を育てていくことができているように感じます。

個人的にも、配信なし前提の泥臭い内容の発表が聞けたり、懇親会での監視や障害対応の興味深い議論に参加できたりなど、運営メンバーとしての役得を感じることも多いです。

参加者の方々へのメッセージ

ここまで盛り上げていただいた参加者や、場所提供などでお世話になっているスポンサー企業の皆様には、感謝の思いです。

せっかく盛り上がった場になっていますので、懇親会での情報交換や更に大きな勉強会へのステップアップなどなど、このゆるSRE勉強会という場をうまく活用していただけたらと思います。

また、運営についての提案に対してはフットワーク軽めに対応させていただいておりますので、改善点や「こんな企画がほしい！」等ありましたらアンケート等で教えていただけますと幸いです！

今後ともどうぞよろしくお願いします！

*1:なお、初回開催時の15分枠での発表で社内メンバーにお願いしたのを除いては、会社の評価制度のハックという意味でもイベントの公平性という意味でも問題があるので、特にLT枠の抽選などで弊社メンバーを優先的に選んだりはしていませんので、そこは誤解なきよう。

*2:あとから見直すと、ちゃんとツイートで需要調査してから動いているように言えるんですが、ぜんぜんそんなちゃんとした意図のツイートではなかったです。

リブセンスに復帰して約半年がたちました

これは Livesense Advent Calendar 2022 DAY 5 の記事です。

こんにちは、かたいなかです。

7月にリブセンスに復帰してからもうすぐ半年になります。出戻りにも関わらず暖かく迎えていただき、この半年間楽しく仕事をすることができました。

この半年どのような仕事をしたかを記事にすることでアドベントカレンダーの5日目の記事とさせていただきます。

TL;DR

  • SRE&採用広報を頑張った
  • 裁量をもってのびのび働け、他の人から刺激を受けられる良い職場

なぜ戻ってきたのか

前回リブセンスを退職したのは、2021年6月のことでした。

転職してからの仕事を行う中で、裁量を持ってのびのび働ける環境でまた働きたいという気持ちが高まり、リブセンスに戻ることにしました。

後述するように、それは正解だったように思います。

この半年やった主な仕事

この半年は、インフラグループでのSREとしての職務をメインにしながら、採用広報チームでのブログやイベントの運営も行っていました。

インフラグループのSREとして

インフラグループのSREとしてはマッハバイトや転職会議を主に担当していました。

転職会議のArgo CD移行

転職会議では主にCI/CD基盤のArgo CDへの移行を行っていました。入社直後に発覚したWeave Cloudのサービス終了期限が迫る中、無事にArgo CDへの移行を終えることができました。

made.livesense.co.jp

プレビュー環境検討とAWS Dev Day 2022 Japan 登壇

転職会議での将来のアーキテクチャを検討する機会がありました。その結果は、プレビュー環境に関する記事や、AWS Dev Day 2022 Japanでの登壇にもつなげることができました。

made.livesense.co.jp

マッハバイトのクラウド移行（進行中）

マッハバイトではオンプレサーバのAWS移行プロジェクトに関わっていました。

Mroongaを使用しているオンプレMariaDBのAurora MySQLへの移行手順の検討・調査を行っていました。DMSを使った移行手順の検証やアプリケーション側での変更が必要な箇所の洗い出しなど、この半年ほどかけてじっくり取り組んできました。結果的にAWS 移行の目処がたち、DB移行作業に関する懸念によってブロックされていた他のクラウド移行作業を進められる状態になりました。

オンプレでの稼働に特化して改善されてきたアプリケーションを、クラウドに対応した形に直していく経験は、「システムのベストな形は前提が代わると全く異なったものになる」ことを実感する良い機会になりました。

採用広報チームとして

採用広報チームのメンバーとしては、エンジニアブログ等の外部発信を活性化させるための活動を行いました。採用広報チームの活動の詳細については、12/25に公開予定の記事もご覧ください。

社内LT大会の企画

採用広報チームでの最初の活動として社内LT大会を企画しました。開催にあたっては、エンジニアブログの記事のネタの発掘や外部登壇の練習の機会になればという思いがありました。

made.livesense.co.jp

結果的に、運営側の予想を大きく上回るクオリティのLTが大量に集まりました。こういった機会を踏み台に自信を持っていただき、どんどん次の活動につなげていってもらえればという思いです。

テクニカルライティング勉強会の企画

外部講師の方を招きテクニカルライティング勉強会を開催しました。「良い文章とはどのような文章か」の認識をある程度揃え、アドベントカレンダーにむけての雰囲気を醸成するという目的がありました。

made.livesense.co.jp

エンジニア以外の方も含む多くの人数の方に参加いただき、質疑応答タイムでも活発に質問が飛び交うなど、大盛況になりました。

アドベントカレンダー運営

そして、現在開催されている2022年のアドベントカレンダーの運営です。

adventar.org

社内の雰囲気など

社内の雰囲気で良かったと感じるのは以下のようなところです。

  • 優秀な同僚から刺激を受けられる
  • 裁量労働を活用できる
  • 高速で技術的負債が返済されている

優秀な同僚から刺激を受けられる

優秀な同僚が多く所属しており、刺激を受けられる環境なのを感じました。広く使われているOSSのコミッターや技術雑誌への寄稿経験者など様々な分野でツワモノが揃っています。

そのような同僚と議論することで一人では思いつけなかったような、スマートな解決策が見つかることがあります。優秀な同僚と建設的な議論を積み重ねる経験により、エンジニアとしての実力を高めていけるのが魅力だと感じています。

裁量労働を活用できる

裁量労働制をみなさんがうまく活用しており、メリハリのある働き方をしています。お子さんの送り迎えのために中抜けする、ワールドカップ期間に寝不足になるため進捗に貯金を作っておくなどです。個人的にも、早めに仕事を終わって釣りばかりしている時期もあり、大きめのタスクを終わらせることに集中して時期もあり、メリハリをつけて働けています。

また、業務内容に関しても裁量が大きく感じており、LT大会やテクニカルライティング勉強会の運営のような、メインの業務とは別のところでの新しい活動についても積極的に応援してもらえる雰囲気がありました。こういった業務内容に関しての裁量の大きさは、負債返済等の業務にポジティブな精神状態で取り組んでいくのにとても重要だと感じています。

高速で技術的負債が返済されている

以前退職したときに負債が多いイメージがあった部署も、1年経って戻ってくると、大きく技術的負債返済が進んでいたりしました。全体的な技術的負債返済や新しい技術・アーキテクチャの採用への温度感が高いのを感じます。技術的投資にかかる時間も業務時間の10%が取れることがルール化されています。この「技術投資10%ルール」によって生み出された成果のいくつかはこのアドベントカレンダーでも記事化される予定です。

半年の感想

リブセンスに戻っての半年の感想ですが、結論として戻ってきてよかったなと感じています。

周りの方のサポートもあり、のびのびと楽しく働くことができました。また、技術的な面で刺激を受けることも多く、自己研鑽のモチベーションが高まっています。

結果的に、外部発信も多く行えた半年となりました。このペースを維持して働いていければと思っています。

NestJS製GraphQLサーバの起動が遅かったので調査した話

こんにちは、かたいなかです。

最近、NestJS製のGraphQLサーバでのSchemaからのTypescriptファイルの生成が遅い問題を調査する機会がありました。

今回の記事では、ツールの使い方等の自分への備忘録を兼ねて、どのように問題に取り組んだかを記事にして紹介します。

TL;DR

  • 高速化するならまずは計測から。計測によるボトルネック特定が最優先。
  • フレームグラフが遅い処理を特定するのに超便利。Node.jsなら0xがフレームグラフ生成に便利。
  • @nestjs/graphql でGraphQLのスキーマからTypescriptのファイルを生成する処理が速くなった。

経緯

最近関わった案件では、BFFとしてNestJS製のGraphQLサーバをスキーマファーストで使用していました。GraphQLによるスキーマファーストな開発の恩恵は日々感じているものの、サーバの起動時や再コンパイルの際に40秒ほど時間がかかってしまっていました。この待ち時間のために行った変更をローカルでサクッと動作確認することができず、フラストレーションが溜まる状態になっていました。

この問題について、GraphQLのスキーマからTypescirptへのコンパイル処理に時間がかかっているのではないか、ということまでは分かっていたのですが、詳しい調査は手つかずとなっていました。

まずは計測してボトルネックを特定

問題の調査にあたってはまず、起動時の処理のフレームグラフを取得し、時間がかかっている処理を特定することを目指しました。

Node.jsでフレームグラフを出すには 0x というツールが便利そうでした。

github.com

そこで、以下のコマンドで起動処理のフレームグラフを作成しました。

$ NODE_ENV=development 0x dist/main.js

フレームグラフをよく見ると、 @nestjs/graphql の graphql-explorer.ast.ts というファイルから呼び出された ts-morph というTypescriptのAST変換のライブラリでの処理に時間がかかっているようでした。

更に調査

@nestjs/graphql の ts-morph の使い方に問題がありそうなことはわかったので、具体的には何が問題なのかを詳しく調べてみます。

ts-morph の公式ドキュメントを見てみると、performanceに関するtipsがまとめられたページがありました。

ts-morph.com

そこで、このページの内容をもとに既存のコードをチェックしてみると、大きく以下の２つの問題があることがわかりました。

  • interfaceやproperty等を一つずつ追加している(このような処理はバッチで一度に行うべき)
  • Structure (簡易ASTを表すオブジェクトで高速化に寄与する)があまり活用されていない

問題修正

問題が特定できたので、早速コードを修正しました。

コードを修正して開発環境で試してみると、以下の画像のように40秒以上かかっていたサーバの起動が3秒程度で終わるようになりました！！！

before

after

PRを作成

実際にサーバの起動が高速化されることも検証できたので、修正PRを作成しました。

github.com

また、リリースを待つ間にも開発メンバーに高速化した起動を体験してもらえるよう、現在のBFFで使用している @nextjs/graphql に合わせたパッチファイルを作成し展開しました。

こちらは正式にリリースされたコードではないため、リリース前等に正式版の nextjs/graphql でスキーマを生成し直して、問題ないかを確認する運用にしています。

まとめ

今回の記事では、GraphQLの起動時間の問題に対してどのように取り組んだかの一連の流れを紹介しました。

ボトルネックの特定から実際のパフォーマンス改善まで一連の流れはNode.jsに限らず様々なパフォーマンス問題の調査で共通するものだと思っています。

この記事がどなたかの参考になれば幸いです。

参考

ArgoCD Image Updaterの新機能でイメージ更新用のPRの作成を自動化する

こんにちは、かたいなかです。

Kubernetes内のリソースを管理する際、Argo CDでのGitOpsは優れたGUIを備えていることなどから魅力的です。最近ではArgo CD Image Updaterというコンポーネントもあるため、Kubernetesでデプロイしたアプリケーションのイメージの更新まで自動で行えるようになっています。

今回はそんなArgo CD Image Updaterのv0.12.0から入った機能で、PRによるアプリケーションのイメージの更新が簡単に自動化できるようになっていたため、実際に動かして検証していきます。

目次

Argo CD, Argo CD Image Updaterとは

Argo CDは、GitOpsでKubernetes内の設定を管理するためのツールです。使いやすいGUIを備えていることも特徴の一つです。

Argo CD Image Updaterは、ArgoCDで管理されているアプリケーションのDockerイメージのリポジトリを監視し、新しいイメージを検出した際にイメージの更新を行うことができます。

この2つを組み合わせることでGitOpsでKubernetes内のリソースを管理しながらイメージの更新を自動化できます。

個人的に使いづらかった点

Argo CD Image Updaterによる変更はデフォルトではArgoCDのApplicationで指定しているリポジトリおよびブランチに書き込まれます。

Image Updaterによるコミット後のイメージの変更の同期は自動にできる(spec.syncPolicy.automated)のですが、その場合デプロイのタイミングの微妙な制御が行いづらくなります。今関わっている案件ではリリースのタイミングをスクラムイベント等に合わせて調整したいため、特に本番への自動デプロイは採用しづらいという問題がありました。

その場合、手動でSyncするという案が考えられるのですが、ArgoCDの権限上、手動Syncを行えるユーザは任意のバージョンへのロールバックも行えるため、本番環境を悪意を持って壊すこともできてしまう状態になってしまいます。そのため、業務委託の方が多い今の環境では採用しづらいです。

また、イメージの変更がリモートブランチへの直接コミットにより行われるため、ロールバックを行う際のRevert作業がGitHub上で完結しないという問題もありました。

新機能

そんな中、ArgoCD Image Updaterのv0.12.0で、ソースブランチに直接コミットさせるのではなく、新しいブランチにイメージの変更をコミットさせる機能が導入されました

この機能でArgoCD Image Updaterでイメージの変更のブランチの作成までを行い、GitHub Actionsでブランチ作成を契機にPRの作成を行うことで、イメージの更新のためのPRの作成が自動化できるようになります。

これにより、新しいイメージのデプロイをPRのマージでいつでも実行できるようにしつつ、ロールバック作業もPRをRevertするだけで行えるようになります。

実際にやってみた

実際にArgoCD Image UpdaterをGitHub Actionsと組み合わせてPRの作成を自動化していきます。

以下の図のようなフローを組んでいきます。

f:id:katainaka0503:20220224010407p:plain

検証した環境

  • Mac OS 12.2
  • Minikube 1.25.1
  • docker desktop 4.4.2
  • Argo CD 2.2.5
  • Argo CD Image Updater 0.12.0

Argo CDのインストール

まずは、こちらのドキュメントに従い、Argo CDおよびArgo CD Image Updaterをインストールします

https://argo-cd.readthedocs.io/en/stable/getting_started https://argocd-image-updater.readthedocs.io/en/latest/install/start/

また、GitHubに接続するためのクレデンシャルの設定もしておきます

argocd repo add https://github.com/${ORGANIZATION_NAME}/${REPOSITORY_NAME} --username ${USERNAME} --password ${PASSWORD} --port-forward --port-forward-namespace argocd

必要に応じてここでDockerリポジトリへの接続の設定をしておくと良いでしょう。今回はパブリックリポジトリのイメージを使用するのでここでは設定しません。

書き込みブランチを指定する機能を試す

ここまででArgoCD Image Updaterの準備ができたので以下のようなApplicationを作成して書き込みブランチを指定する機能を試していきます。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: test-service
  namespace: argocd
  annotation:
    argocd-image-updater.argoproj.io/image-list: some/image[:<version_constraint>]
    argocd-image-updater.argoproj.io/write-back-method: git
    argocd-image-updater.argoproj.io/git-branch: :image-updater{{range .Images}}-{{.Name}}-{{.NewTag}}{{end}}
spec:
  destination:
    namespace: test-service
    server: https://kubernetes.default.svc
  source:
    repoURL: https://github.com/katainaka0503/argocd-image-update-test.git
    targetRevision: main
    path: test-service
  syncPolicy:
    automated:
      prune: true

ポイントはargocd-image-updater.argoproj.io/git-branchアノテーションの値に :が含まれていることです。 値の:で区切られた左側は新しいブランチのチェックアウト元のブランチになります。そして、右側は新しいブランチの名前のテンプレートを指定します。

このApplicationを作成した状態で、新しいDockerイメージをpushすると、以下の画像のようにGitHub上にイメージ更新のコミットを含んだ新しいブランチが作成されます。

f:id:katainaka0503:20220224004502p:plain

GitHub Actionsと組み合わせてみる

ArgoCDによってイメージ更新用の新しいブランチの作成まで行えるようになったので、もう少し工夫してGitHub ActionsでPRの作成まで自動化します。

以下のようなファイルでGitHub Actionsのワークフローを作成します。

name: create-pr-for-image-updater

on:
  push:
    branches:
      - 'image-updater-**'

jobs:
  create-pr:
    runs-on: ubuntu-latest
    steps:
      - name: Create Pull Request
        uses: actions/github-script@v6
        with:
          script: |
            const { repo, owner } = context.repo;
            const result = await github.rest.pulls.create({
              title: '[Image Updater] イメージの更新',
              owner,
              repo,
              head: '${{ github.ref_name }}',
              base: 'main',
              body: 'Dockerイメージを更新します'
            });

この設定がmainブランチにある状態で再度ArgoCD Image Updaterにイメージ更新ブランチを作成させると、PRが自動で作成されます。

f:id:katainaka0503:20220224004630p:plain

実運用ではPR作成処理実行時に古いブランチを削除したりするとよいでしょう。

また、複数の環境用に複数のブランチを使うフローになっている場合はブランチ名等にPRの対象のブランチ名を含ませるようにすると柔軟に対応できそうです。

さらには自動マージ等も併用することでステージング環境へのデプロイはレビュー不要にすることもできます。

まとめ

ArgoCD Image Updaterの新機能を使うことでイメージの更新のPRの作成までを自動化することができました。イメージの更新がPRベースなため、スクラムイベント等のデプロイを行いたいタイミングに合わせてデプロイできます。また、GitHubのApprove関連の設定により誰がデプロイを行えるかを設定できるようになりました。さらには、ロールバックが必要になった際のRevertもGitHub上の操作で完結します。

今回の機能はかゆいところに手が届く機能で個人的にもとても嬉しい機能です。この機能がリリースされたらArgoCDを使っている環境では試してみる価値があるのではないでしょうか？

余談: Fluxでは

Argo CD + Argo CD Image Updaterの機能を提供する他のツールとしてFluxというツールがあります。FluxではPRの作成までGitHub Actionsに頼らず行うことができるようです。

https://fluxcd.io/docs/use-cases/gh-actions-auto-pr/

今回のリポジトリ

参考

編集履歴

  • ArgoCD Image Updater 0.12.0リリースに伴い、リリース前の機能を使うためのセットアップ手順を削除しました。

マイクロサービスの運用をスケールさせるにはどうしたらいいんだろう

こちらは、Livesense Adventcalendar 2021 19日目の記事です

こんにちは、かたいなかです。最近、マイクロサービスで構築されたシステムをインフラの運用を破綻させずにスケールさせていくために必要なことをずっと考えています。

自分のための備忘録も兼ねてマイクロサービスを破綻させずにスケールさせていくためにSREの観点で使う技術に関係なく最低限必要だと考えていることをポエム記事としてまとめてみます。

問題

システムが巨大になってくると、マイクロサービスの数や関わるエンジニアの数に比例してインフラの運用工数が増えていきます。インフラの運用工数が増え続けると、いずれサービスレベルの低下やインフラ作業のリードタイムの増大に繋がり、システムの品質や開発効率に悪影響を及ぼします。

この問題に対処するために、運用工数の増大に対してスクリプトによる自動化等で工数を減らすというのがよくある打ち手ですが、マイクロサービスごとに構成が異なったりするとに簡単に自動化できなかったりします。 そんなふうにして自動化が遅れていると、最終的に自動化によって運用工数が減るペースよりもシステムの成長に伴って運用工数が増えるペースのほうが大きくなり、自動化による解決が難しくなります。 そうすると、自動化ではなく抜本的にシステムを作り変え解決を図るのですが、これもシステムの大きさが大きくなればなるほど移行完了までかかる時間がかかることになり、ビジネスに対する影響が大きくなってしまいます。

個人的な経験でも、このような状態に陥りながらも運用エンジニアのがんばり等でなんとかシステムを動かし続けているシステムは世の中に沢山存在するのではないかと思っています。

そのような状態に陥ってしまうのをできる限り避けるにはどのようにしたら良いでしょうか？

こうしたらいいんじゃないかと思っていること

上記のような問題はよくある問題だと思いますが、個人的にこのような問題に対処するにはSREの観点では以下のような対策が必要ではないかと思っています。

  • トイルの量の計測

  • システムの標準化

  • 作業の自動化・運用のセルフサービス化

それぞれについて具体的に書いていきます。

トイルの量の計測

なによりもまず運用コストがどの程度なのか計測する必要があると思っています。計測することにより、トイルが増えすぎて改善に手が回らない手遅れの状態になる前に改善に向けた施策を検討することができるようになります。

計測には例えばtogglのようなツールにより計測したトイルにかかっている時間やトイルに分類されるチケット数を用いることが考えられます。また、開発者自身が行っている作業の中でもトイルとなっている作業があるかもしれないため、開発者サーベイ等の結果も併用すると良いでしょう。

測定した値をインフラチーム内で定期的に共有し、どのような種類のトイルがあるか等を定期的に分析すると良いでしょう。トイルを減らすにはどうしたらよいか優先的に自動化するべきタスクはどれかなどSRE内部で定期的に議論する場を設定します。トイルの量が増えすぎた場合には運用を破綻させないために行う作業の量を制限する必要があるかもしれません。

システムの標準化

マイクロサービスごとに構成に大きな差分があるとシステム全体の認知コストが大きく増大します。認知コストが大きいシステムは自動化やセルフサービス化等の取り組みを行うのが難しくなります。 そのため、なるだけ自然に標準的な構成に従えるようなしくみを準備する必要があります。

標準的な構成等について書かれたドキュメント等はどのシステムにもあると思いますが、個人的にはそれだけでは不十分だと考えています。マイクロサービスの場合、特に複数のチームのエンジニアが関わることになりドキュメントへの準拠を担保できなくなるためです。

たとえば、Terraformを使用して運用している場合にはlint, tfsec, モジュール機能等を使用し、可能な限り自然に標準に従えるようにし、違反した場合には自動で検出できるような仕組みを考えていく必要があります。

このとき、すべてのシステムを標準に合わせようとすると無理が出てくるため、8~9割程度を標準でカバーし残りの1割を個別運用するようにすると現実的かと思います。

作業の自動化・運用のセルフサービス化

システムの成長に伴って増えていくトイルに対して、まず浮かぶ対策はスクリプト化等による自動化です。また、システムの構成変更やクラウドサービスの新機能の導入等により作業自体を不要にしてしまうこともできるかもしれません。

このような自動化を行っていく中で、開発に必要な作業は可能な限りインフラに依存せずセルフサービスで行えるようにしていく必要があります。開発者自身がオーナーシップを持って運用していくことは高品質なシステムを構築する上で不可欠です。また、インフラエンジニアの数はアプリケーション開発者の数に比べて限られているため開発者側で行える作業はセルフサービスで行ってもらうことが合理的です。

このようなセルフサービス化の対象には、新バージョンのデプロイや環境変数の修正、エラー調査に必要なログの取得や新しいマイクロサービスのデプロイやマイクロサービスごとのダッシュボードの作成、まで様々な作業が含まれます。

このようなセルフサービス化に伴いSLOや権限の管理等でガードレールを設けていく作業も同時に行うことで品質やセキュリティの担保も行っていくとよいでしょう。

個人的にはセルフサービス化等により先回りして開発者の作業が快適に行える環境を作っていくことこそSREの仕事なのではないかと思っています。

雑感

個人的にはトイルの増大に早めに対処していくことこそがSREの本質だと思っています。

SRE本ではトイルの量を工数の50%に抑える必要性が述べられています。最初読んだときにはやりすぎではないかと思っていたのですが、最近様々なシステムに関わることが増えるにつれて運用が個人の頑張りに依存せず持続可能な状態を維持していくためには現実的に必要な対処ではないかと思っています。

参考資料

TOEIC L&R 980 取得記

2020年9月13日に行われた第252回 TOEIC® Listening & Reading 公開テストにて 980 点を取得しました。他の方の参考になればと思い、使用した参考書や行った勉強法を共有します。

f:id:katainaka0503:20201006170913p:plain

TL;DR

  • 「目標点をとる上で自分に足りない能力はなにか」「しっかり負荷がかかる学習が行えているか」を意識しながら学習を行うことが一番大事
  • DUO3.0とCore1900で基礎的な英単語をみっちり鍛えることでTOEIC対策に耐える基礎力をつけましょう。時間をかければ新しい単語や表現の意味を思い出せる状態でやめないこと。英会話レッスン等と組み合わせて覚えた単語を自在に使える状態まで持っていくことが重要。
  • 速読速聴・英単語 TOEIC TEST GLOBAL 900 はTOEICの問題に似た文章で英単語を覚えていく形式であり、TOEIC風の文章に慣れながら単語を覚えていけるため強くおすすめできる。
  • Part2とPart5は対策が効きやすいパートであり、対策のコスパが非常に高い。
  • 公式模試を解き終わったら本番より難しめの模試を解くのがおすすめ。私は精選模試2のリスニング・リーディングを使用

具体的な学習内容以前の話

使った参考書やWebサービス等の解説の前に先に書いておきたいのですが、「この記事に書いてあったからこの本をやる」「この記事に書いてあったから参考書をN回繰り返す」というスタンスで勉強に取り組んでいるうちは個人的にはどこかでTOEICの点数が頭打ちになってしまう可能性が高いんじゃないかと思っています。

あくまでこの記事で書かれていることは参考程度にとどめ、「目標を達するために自分に今足りない能力はなにか」「どのようなトレーニングを行うと目標に近づけるか」「今の学習方法はしっかり負荷がかかる方法になっているか(特にシャドウイング)」を常に自問自答し、学習法を決めていくことをおすすめします。

具体的な学習内容

英語学習スタート前の状態

  • 小中学校では英語が比較的得意だった
  • 高校時代にDUO3.0を使ったことがある
  • 大学受験をしなかったので大学受験のための英語学習は未経験
  • TOEIC受験経験なし

TOEIC用の勉強開始前(2019.06 ~ 2020.5)

この頃は特に資格試験を受けるつもりはなく、「英語のドキュメントや海外カンファレンスの動画を理解できるのってかっこいいな」という単純な動機で学習をはじめました。

当初の動機は仕事で活かすことでしたが次第にレアジョブのレッスン内でいかにうまく話せるかということに主眼が移っていきました。

今から考えるとすぐにTOEIC対策に取り掛からず、DUO3.0やCore1900および英会話レッスンで基礎的な英語力をじっくり高めたことが、後のTOEICでの高得点につながったのではないかと思います。

英会話レッスン(レアジョブ)

この時期に英語学習の中心になっていたのはレアジョブというサービスでの1日25分の英会話レッスンでした。

レアジョブのレッスンでは、最初は日常会話用の教材を使っていたのですが、レッスンに慣れた後はDaily News Articleという教材を使っていました。この教材は毎日配信される記事を題材にディスカッションするというもので、記事の内容が面白く毎回レアジョブの先生と議論するのが楽しかったのを覚えています。

ただレッスンを惰性で受けるだけでは受動的な学習になってしまい効果が薄いと感じたため、瞬間英作文の練習やDUO3.0/Core1900の音読・シャドウイングを行った直後にレッスンを受けるようにしていました。これにより、覚えたばかりの能動的に使うことができない語彙を自然と背伸びして使うことになったため、結果として能動語彙が増え、能動語彙が増えると英会話のレッスンが楽しくなるという良いループが生まれていました。

瞬間英作文

英会話のレッスンを受け始めてすぐに、言いたいことを文章の形で伝えることができないという壁にぶつかったため瞬間英作文の練習を行いました。

中学校で習うような英文を文字通り瞬間的に英作文する学習法です。

上記2冊の参考書でしばらくトレーニングを行うことで、簡単な英文であれば一瞬で口から出せるようになりました。

ある段階で瞬間英作文は卒業して単語帳のシャドウイングに練習の中心を移したのですが、TOEIC用の勉強を始めた後も特定の文法が苦手(使役動詞等)だと感じたら瞬間英作文風に作文して練習するなど、文法を能動的に使える状態に持っていく方法としては学習期間を通して活用していました。

単語帳

よく使われる表現を覚え英会話で役立てるためにDUO3.0とCore1900という2つの単語帳を使用しました。この頃はTOEICの受験は考えていませんでした。

DUO3.0

DUO3.0は1600個の重要単語と熟語1000個を560本の基本例文を通して覚えていく、いわゆる短文型の単語帳です。Natto smells awful but tastes terrific.　のような短文の中に覚える必要がある単語が散りばめられており、例文を暗記するだけで重要な単語を効率的に覚えられます。短文自体も退屈にならないように工夫がされており、ドジなボブの話などクスッと笑ってしまうような短文も多いです。

別売りで基礎用と復習用の2種類のCDが発売されているのですが、CDのあるなしで学習効率が段違いなのでかならずCDを入手し耳も使って覚えていくと良いと思います。基本的には復習用のみ買えばシャドウイング等の練習には十分です。

レアジョブのレッスン前の準備体操として毎日1冊の1/4程度をシャドウイングし、土日など時間がある時に音読をするという感じで1ヶ月程度使用していました。高校時代に学習教材として使っていて内容を半分程度覚えていた状態だったため、完全に初見の方はもう少し長めにやっても良いかもしれません。

速読速聴・英単語 Core1900

速読速聴・英単語は単語帳の中で個人的に最もおすすめできるシリーズです。

このシリーズはいわゆる"文脈型"単語帳であり覚える必要がある単語が散りばめられた 120 語程度の文章を使って単語を学習していきます。長文を使って学習していくので、シャドウイングや音読の教材として使うことで新しい単語を覚えることにとどまらず、リスニングや長文読解等すべての英語力をバランス良く伸ばせる教材だと感じています。

Core1900はPart1とPart2に分かれていて、Part1は120語程度のニュース記事とその中に登場した見出し語がまとまっているいわゆる文脈型単語帳の形式、Part2はDUOのような短文型単語帳形式です。特にPart1の文章には「光害の問題」など読み物としても普通に面白い記事が多くおすすめできます。

新しい記事に取り組む際には以下のようにしていました。

  • 英文を一度も読んでいない状態で音声を3回程度聞き、耳だけで英文を理解する練習をする
  • 英文を読んで聞き取れなかった部分・新しい単語を確認
  • 3回音読
  • シャドウイングを数回(1.2 倍速まで次第にスピードアップ)

この本で出た表現は、2ヶ月程度この本音読・シャドウイングをした直後に英会話レッスンを受けることを繰り返すことで、一部の難しい表現を除いて英会話の中で自然に使える状態を目指してトレーニングを行っていました。これにより基礎的な単語の運用力がかなり鍛えられました。

TOEIC 勉強開始(2020.05 ~ 2020.07)

レアジョブのレッスン内で自信がついたので、力試しを兼ねてTOEICを受けてみようと学習を開始しました。

この時期に最も重視したのは以下です。

  • TOEIC用単語の習得
  • TOEICのリーディングパートより少し難しい記事の多読によるリーディングスピードの向上
  • Part2対策(対策が行いやすいため早めにスタート)
  • Part5対策(対策が行いやすいため早めにスタート)

TOEIC用単語

速読速聴・英単語 TOEIC TEST GLOBAL 900

TOEIC用単語の習得には主に速読速聴・英単語 TOEIC TEST GLOBAL 900を用いました。

TOEICのPart3,4,6,7のような文章を使って単語を覚えていく文脈型単語帳です。使用法はCore1900のときとほぼ同様で、音読・シャドウイングを繰り返し、直後に英会話レッスンを受けることでなるべく新しく学んだ語彙を能動的に使える状態を目指して練習しました。

個人的にはこの本で飽きるまでTOEICっぽい文章を音読・シャドウイングしたことでリスニング力とリーディング速度の両方に効いたと感じており、TOEIC対策単語帳として強くおすすめできます。

金のフレーズ

GLOBAL 900の補助としてTOEIC L & R TEST 出る単特急 金のフレーズ(通称金フレ)を使用しました。こちらは語彙に抜けがないことやTOEIC特有の語義等をチェックするために使いました。ただ、個人的にフレーズで覚えていくスタイルが肌に合わなかったので2周程度でやめてしまいました。

Japan Timesの記事を読む

TOEIC のリーディングパートよりやや難しい文章でリーディング速度向上トレーニングをするため、Japan Timesの記事を空き時間で読むようにしていました。

新しい記事を読む際には以下のように読んでいました

  1. 時間を計測しながら読む
    • 意味がわからなくなったり文章構造が掴めなくなってもなるべく戻り読みをしない
    • 英単語の意味は調べない
    • どのあたりに何が書いてあったかなんとなく理解できる程度の理解度で読めるのが理想(Part7のような問題を解くために必要な情報が文章のどのあたりに書かれていたかぼんやりわかるぐらい)
  2. 読み終わったら単語数を時間で割り、おおよその WPM を確認する(私の場合はWPM160ぐらいで理解度を最大にするため、WPMを元に読み方を調整していました)
  3. 同じ記事を時間をかけて文章構造を正確に把握することを意識しながらもう一度読む。英単語は記事の意味を理解するのに支障がある場合だけ調べる

Part5 対策

Part5 の対策としては、まず Evergreen(旧 Forest)を問題集を合わせて一通り通読しました。

後から考えるとこの本は重箱の隅をつつくような文法事項の解説も多く、通読するよりも辞書的に使ったほうが効率的だったかもしれません。

その後、Evergreen(旧 Forest)を 7 割程度頭に入れた状態で以下の問題集を使って対策を行いました。

多いようですが、Part5は明らかに対策が効きやすいパートであると感じていたため、対策を重点的に行いました。

Part2 対策

Part2 の対策としては、以下の問題集を用いて問題演習および聞けなかった問題の復習を繰り返しました。

Part2 の勉強では必然的にたくさんの短い文を聞くことになるため、自分がリスニングする上で苦手な音や表現を自覚することができました。

以下の参考書もレビューが良いので Part2 が苦手な方は追加で取り組んでも良いかもしれません

受験直前期(2020.07 ~ 2020.09)

直前期には以下の模試をひたすら解いていました。

精選模試は本番より難しいという評判なのですが、難しい問題を高地トレーニングとして解き、また一度解いた難しい問題を使ってリスニングの練習等を行ったことで、本番ではかなり余裕を持って解答できました。

模試を解くときには以下のようにしていました。

  • 新しい模試を解く・採点
  • 間違えた問題・わからなかった単語の確認
  • Part2 で聞けなかった問題をリストアップ・数回聴く
  • Part3,4 を1.3倍速でシャドウイング(何日かに分けて 3~5 周)
  • 1.3倍速にしてリスニングパートを再度解く(リーディングパートは解かなかった)

1.3倍速でリスニングパートを再度解いたのは、先読み等の解答プロセスに集中した練習を行うためでした。模試を解く中で先読みが苦手だと感じていましたが、一度解いた問題を1.3倍速再生しながら先読みの練習をすることで、普通の速度で問題を解く時に余裕を持って先読みが行えるようになりました。

模試の素点

個人的に模試を解いている際に、「模試の素点が何点ぐらいなら本番で目標点に達するか」がわからなくてとても不安だったため、せめてもの目安になればと私が模試を解いた際の素点を晒しておきます。

L R 備考
公式模試 6 T1 91 92
公式模試 6 T2 94 97
精選模試 2 T1 77 93 精選模試の洗礼で大きく L が下がる
精選模試 2 T2 93 91
精選模試 2 T3 88 93
精選模試 2 T4 89 94
精選模試 2 T5 89 98
公式模試 5 T1 98 94
公式模試 5 T2 98 97
公式模試 4 T1 97 97
公式模試 4 T2 99 94

精選模試には本番での予想得点の換算表が載っているのですが、私個人の話で言うと本番では換算表の点数より+20~30点ぐらいの点数が出たのでこちらも参考として。

まとめ

ここに紹介したような対策でTOEICの本番では980点を獲得することができました。誰かのお役に立てば幸いです。

Kubernetesにシステム系コンポーネントを入れるときは監視も一緒に設定しよう

Kubernetesの利点の一つとしてOSSのコミュニティで開発された独自のシステム系コンポーネントを導入することで、自分たちのニーズに合わせた運用性の向上が望めるという点があります。

転職会議でもALB Ingress ControllerやSealedSecrets等のシステム系コンポーネントを導入しています。

このようなコンポーネントは多くの場合ドキュメントに従って手を動かすだけで（場合によってはYAMLをクラスタに適用するだけで）導入が完了するほど容易に導入できるのですが、ここで見落としがちなのが導入後の運用です。運用を滞りなくおこなうためには導入されたコンポーネントは当然監視されている必要があります。

転職会議ではDatadogのAutodiscovery機能を使用してPrometheusのエンドポイントからDatadogにメトリクスを取得して監視を行っているのでその設定例等を紹介します。

何を監視したいか

転職会議ではEKS上に以下のようなコンポーネントを導入しています。

  • Flux
  • Sealed Secrets
  • Velero
  • Reloader
  • AWS ALB Ingress Controller
  • Cluster Autoscaler
  • ExternalDNS

このとき例えば以下のような問題が起きたらすぐにSlack等に通知させたいです。

転職会議ではSREだけではなくアプリケーションエンジニアも自分が担当するサービスのKubernetesのYAMLを日々編集しています。そのためSREとしては、上のような問題が起きた場合には本番だけでなくステージングや開発環境でもなるべく早く開発者に知らせてあげることで、安心してKubernetesのYAMLを修正しやすい環境を作りたいと考えています。

そのため、独自システムコンポーネントの監視によって問題発生時にはすぐに通知されることは重要です。

どうやって監視するか

実は多くの場合独自のシステム系コンポーネントにはPrometheusのエンドポイントが生えているため、Prometheus形式のメトリクスに対応したツールを使うことでこれらのメトリクスを監視に用いることができます。

例えばALB Ingress Controllerであれば 10254 番ポートの /metrics というパスにアクセスすることで以下のようなPrometheus形式のメトリクスが返ってきます。

...略....
aws_alb_ingress_controller_aws_api_errors{operation="DescribeListenerCertificates",service="elasticloadbalancing"} 2
aws_alb_ingress_controller_aws_api_errors{operation="DescribeLoadBalancers",service="elasticloadbalancing"} 9
aws_alb_ingress_controller_aws_api_errors{operation="DescribeTargetGroups",service="elasticloadbalancing"} 15
aws_alb_ingress_controller_aws_api_errors{operation="GetToken",service="ec2metadata"} 1
aws_alb_ingress_controller_aws_api_errors{operation="ModifyRule",service="elasticloadbalancing"} 38
aws_alb_ingress_controller_aws_api_errors{operation="RegisterTargets",service="elasticloadbalancing"} 7
...略....

このようなPrometheusのエンドポイントから取得したアプリケーションの動作を表すメトリクスを用いて問題発生時にアラートを飛ばすことができます。監視ツールとしてPrometheusを使用している場合はAlertmanager等を使ってアラートを飛ばすことができます。

転職会議では監視にDatadogを使用しているため一旦Datadogにメトリクスを集めて、Datadogからアラートを飛ばすようにしています。

その際に使用しているのがDatadogのAutodiscovery機能です。監視対象のPodに以下のようにアノテーションを設定するだけで、Datadog AgentがPodのアノテーションを解釈し自動的にメトリクスをDatadogに送るようになります。

# 以下はCluster AutoScalerでの設定例
# Podのアノテーション
annotations:
  # datadogでPrometheusエンドポイントからメトリクスを取得する
  # ad.datadoghq.com/<コンテナ名>から始まるアノテーションを設定
  # コンテナ名はPodのcontainers[].nameで指定している名前
  ad.datadoghq.com/cluster-autoscaler.check_names: '["openmetrics"]'
  ad.datadoghq.com/cluster-autoscaler.init_configs: '[{}]'
  ad.datadoghq.com/cluster-autoscaler.instances: '[
    {
      # Prometheusエンドポイント
      # "prometheus_url": "http://%%host%%:<ポート番号>/metrics",
      "prometheus_url": "http://%%host%%:8085/metrics",
      # Datadogのメトリクスのnamespace。
      # これによりDatadog上でのメトリクスが"<ここで設定したnamespace名>.<メトリクス名>"というような名前になる
      "namespace": "prometheus",
      # 取得するメトリクス名のフィルタ 
      # "metrics": ["<metrics名のフィルタ>"]
      # Goのランタイムのメトリクス等も取りたいなら以下
      # "metrics": ["*"]
      "metrics": ["cluster_autoscaler_*"]
    }
  ]'

あとはDatadogの機能で普通にアラートを設定するだけです。Slackに通知すると以下のような感じです。

f:id:katainaka0503:20200811164840p:plain

まとめ

運用を楽にするような独自コンポーネントを導入しやすいのはKubernetesの大きな利点です。この大きな利点を最大限に利用するためにも、新しいコンポーネントを入れる際には監視やアップデートを含めたプロダクトのライフサイクルで起こりそうな問題を考えておくようにしましょう。

参考資料