継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

『TechBrew in 東京 〜SRE大集合！信頼性を高める取り組み〜』に参加して各社の信頼性向上の取組みを学んだ

SRE LT 勉強会

タダです.

「TechBrew in 東京 〜SRE大集合！信頼性を高める取り組み〜」に参加してきたので,参加の感想をまとめていきます.

findy.connpass.com

イベント概要と参加目的

「自社では信頼性を高めるためにどのような取り組みを行っているのか？」をテーマのLTで各社の取り組みを共有し合える場

転職以降に他社の事例を聞いたり,話す機会がかなり減ったのを危惧して今回参加させていただきました.

発表のサマリーと感想

各発表ごとにサマリーと感想をまとめていきます.

SREに活かすセルフ・アウェアネス

@syossan27さんによる SRE 文脈でのソフトスキルに関するお話でした.SRE に限らず組織で働くことは組織内で協調していく必要があると思いますし,Indeed 社では求人票に書かれているのは印象的でした.また,ポストモーテムで非難しないのは当然としてなぜなぜ分析をしてしまうと自己嫌悪に陥りやすいため What から入るのも印象的でした.

発表資料

SIEMってサイトの信頼性向上に寄与するの？

@yuta_k0911さんから SIEM を使ったセキュリティログ分析のお話でした.セキュリティログ分析はなかなか手を回すのは後手になりがちな印象がありますが,SIEM OpenSearch を使うことで分析しやすさがあるんだなという学びがありました.そして,分析するだけでなくプロアクティブなアクションにつなげていくことで信頼性向上に繋げる考え方は自分自身,足場を固める活動として日々やらねばと背筋が伸びました.

発表資料

チームと成長するSRE

@maruloopさんから開発者の成長とSREの成長に関するお話でした.自分が所属してきた組織で SRE のメンバーから導入したツールや仕組みなどは属人的になりがちな印象で,それらを如何に他の人に技術伝承していくかが長期的に大事だと思っています.考え方次第ですが,特定の人への負荷集中や人依存につながるのは個人的に良くないと思っていて同じ組織で可能な限り同一のオペレーションをできて全体としてのパフォーマンスが高い状態になったほうが良いかと思います.なので,発表の中での定期ハンズオンや SRE チームが各メンバーごとの多重ワークを許容し議論できる状態にあるのは素晴らしいと感じました.

発表資料

トイル撲滅から始める改善手法とその結果

@yjszk666さんの解決されたトイル撲滅のお話でした.トイル撲滅はむちゃくちゃ喫緊で自分も潰した話があったので共感の嵐でした.中でもトイルを誰もやりたくない仕事と定義してからそれを拾いに行ってから潰すムーブとトイルを潰す空気を作れているのが最高で,改めて自社のトイル撲滅をもっとやって向き合うべき課題の時間捻出に繋げたいと思いました.

関連記事

made.livesense.co.jp

発表資料

ジョインしたてのSREが信頼性向上に取り組む(監視設計編)

KK さんによる監視設計のお話でした.監視設計をビジネスフレームワーク(5W1H)に落とし込んでやっているのは初めて見た切り口ではありましたが,各設計項目ごとに必要な考慮事項が整理しやすくなるかもなと思いました.

イベントレポート zenn.dev

発表資料

ガチめなインフラエンジアから見たSRE

@barieroさんのキャリアで初めて SRE ロールになってからどんなことが求められているかを考察された発表でした.SRE がサービスの信頼性を高めるところを主眼に置いて関わるっていうのは同意で今後の信頼性向上の取組みも気なった発表でした.

発表資料

入社1ヶ月目でSREチームの方針とあり方を見直している話

@ohsawa0515さんによる出向された組織での SRE チーム方針とあり方を見直しているお話でした.技術組織はチームトポロジーに沿った組織体になっていて,SRE チームはプラットフォームの分類になっていたそうです.しかし,様々な課題から現場は各チームに Embeded SRE の形ではいっていき課題解決にあたられています.自分自身もやはり感じるのは課題に取り組みやすくするためにそのチームに所属して一緒に課題を解くことだと思っているため,その後の活動込みでどういう課題改善なされるのか楽しみになりました.

発表資料

Datadog実行基盤をEC2からECSへ移行してみた

@Y0u281さんによる Datadog の実行基盤の移行のお話でした.最初の課題提起から実行基盤を ECS に乗せる過程で得られるメリットとそれに伴う実績コストを評価した上で実行されてて Fact ベースな判断をされていて素晴らしいし,コスト削減にもつながっていて一石四鳥では？と思うほど取り組みでした.

発表資料

懇親会

お酒飲みつつ,各社のお話や雑談をさせてもらって楽しかったです.

全体の記念写真

個別で延長戦させてもらった時の写真

まとめ

久々のオフライン勉強会に参加して各社の取組みを聞くことができて勉強になりました.来週は CI/CD のテーマの勉強会があるので,これも参加してレポートを書きます.

findy.connpass.com

Amazon OpenSearch Service でスローログを有効化しているのにログがでない...?時の解決方法を試した

AWS Elasticsearch ログ分析

タダです.

Amazon OpenSearch Service でスローログを有効化しているのに何もログがないって思ったことはありませんか？自分はあります.これでは遅いクエリの分析ができない...そんな状況からログを出すことができたので対処法をまとめていきます.

Amazon OpenSearch Service のログ有効化する方法

そもそも Amazon OpenSearch Service でログを有効化する方法はどのようにするかというと,ドキュメントにコンソール利用の方法と AWS CLI,AWS SDKの記載があり,これに従って設定していきます.

スローログの閾値を設定する

本題ですが,スローログを有効化してもログが出てこないのは閾値を設定してないからです.閾値の設定の仕方はドキュメントに記載があります.つまり,Amazon OpenSearch Service に対して PUT リクエストを送り閾値を設定するということですね.以下,curl でリクエストを送った場合の例になりますが,1秒以上かかるリクエストを WARN ログとして出力する例です.

$ curl -XPUT 'domain-endpoint/index-name/_settings' -H 'Content-Type: application/json' -d '{
"index.search.slowlog.threshold.query.warn": "1s"
}'

関連ドキュメント docs.aws.amazon.com

これで curl domain-endpoint/index-name/_settings?pretty を叩いて slowlog のセクションが出ていれば CloudWatch Logs にスローログが出力されます.

$ curl domain-endpoint/index-name/_settings?pretty
{
  "index-name" : {
    "settings" : {
      "index" : {
        "search" : {
          "slowlog" : {
            "threshold" : {
              "query" : {
                "warn" : "1s"
              }
            }
          }
        }
  ~中略~
}

なお,スローログのフィールド情報は下記ページに日本語記事の解説があり,大変勉強になりました.

www.elastic.co

まとめ

Amazon OpenSearch Service でスローログに何も出ない場合の理由とその対処をまとめました.

CloudWatch Logs のログから秒,分,時間ごとの件数を集計する時にむちゃくちゃ重宝した構文の紹介

AWS CloudWatch Logs Insights ログ分析

タダです.

CloudWatch Logs から時間ごとのログの件数を集計することがあったのを今回の調査で初めて知ったのでまとめておきます.

stas 構文

それは stats 構文で名前の通りログのパターン分析に役立つ役割のようです.下記のクエリでは Exception の件数を5分ごとに集計して降順で表示することができます.

filter @message like /Exception/
| stats count(*) as exceptionCount by bin(5m)
| sort exceptionCount desc

docs.aws.amazon.com

この bin(5m) の値は例えば,1秒毎であれば bin(1s) とできるし,1時間毎であれば bin(60m) とすれば時間の間隔を調整して集計できます.今回自分は,膨大な CloudWatch Logs の中から特定のログパターンで発生したリクエストの件数を集計しレポートする役割を持っていたので,この stats 構文を使っての集計はとても役立ちました.

まとめ

今回は時間毎のログ集計で役立った stats 構文の紹介でした.

SecurityHub の違反してるリソースの検出されたリストを出力する方法をまとめる

AWS Security Hub セキュリティ

タダです.

先日SecurityHub を運用していて違反しているリソースを通知することはやっていてアラートを放置してしまっていたので,その違反の修正を方針を決めてやりました.その際に,違反してるリソースを一覧で出す時の方法を実践して学んだのでまとめておきます.

AWS マネジメントコンソールから出力する場合

マネジメントコンソールから出力する場合は検出ルールの詳細からDownload ボタンを押すと CSV ファイルをダウンロードできます.Compliance Status,Severity,ID, Title, Failed checks , Unknown checks , Not available checks , Passed checks , Custom parameters の順番のカラムで出力されます.

ただ,この段階ではどの AWS リソースで違反が発生しているかはわからないため,個別のチェックツールを詳細で見て Failedステータスのルールを確認すると違反したリソース一覧を確認できるため,これで修正対応をしていくことができました.

AWS CLI から出力する場合

既に検索したら多くの記事が公開されていたのですが,下記の記事を参照させてもらいました.「5. 以下の条件に合致したコントロール数を取得」で利用しているコマンド の部分のコマンドでほしい結果を得られました.

blog.serverworks.co.jp

まとめ

SecurityHub の違反してるリソースを一覧で出す時の方法をまとめました.

The next-generation Slack platform に入門する[ローカルからデプロイ編]

Slack next-gen Slack platform Getting Started

タダです.

前回からの続きです.ローカルで The next-generation Slack platform のローカル開発するのをやってみました.この記事では開発したのをデプロイしてみます.

sadayoshi-tada.hatenablog.com

ローカルからデプロイする

slack deploy で Slack platform にデプロイできました.

❯ slack deploy
? Choose a deployed environment taddyteam hogehoge hogehoge

📚 App Manifest
   Updated app manifest for "hello-world-app" in "taddyteam"

🏠 App Install
   Installing "hello-world-app" app to "taddyteam"
   Updated app icon: assets/default_new_app_icon.png
   Finished in 4.0s

⚡ Listing triggers installed to the app...
   There are no triggers installed for the app

⚡ Create a trigger
   Searching for trigger definition files under 'triggers/*'...
   Found 1 trigger definition file

? Choose a trigger definition file: triggers/greeting_trigger.ts

⚡ Trigger successfully created!

   Send a greeting ABCDEFG (shortcut)
   Created: 2024-01-17 22:48:47 +09:00 (0 seconds ago)
   Collaborators:
     Sadayoshi Tada @tada hoge
   Can be found and used by:
     everyone in the workspace
   https://slack.com/shortcuts/ABCDEFG/hogeghogehoge


🎁 App packaged and ready to deploy
   0.016MB was packaged in 0.5s

🚀 hello-world-app deployed in 8.6s
   Dashboard:  https://slack.com/apps/hoge
   App Owner:  tada (hoge)
   Workspace:  taddyteam (hogehoge)

🌩  Visit Slack to try out your live app!
   When you make any changes, update your app by re-running slack deploy

💌 We would love to know how things are going
   Survey your development experience with slack feedback --name platform-improvements

超簡単に Slack App ができました 🎊

動作確認

slack deploy 時に出ていたショートカット用のURL( https://slack.com/shortcuts/ABCDEFG/hogeghogehoge ) をポストするとローカル開発と同じように hello world app が起動してきました.その後,Start Workflow からメッセージの投稿もできたので動作確認ができました.

まとめ

一旦この記事までで Slack CLI からテンプレートで Slack App を作りそこから App をSlack platform 上にデプロイして使うことができました.引き続き慣れるためにいろんな学習コンテンツをさらった内容を備忘録に記録してきます.