はじめに こんにちは、皆さん。今日は、シェルスクリプトを使った高度な自動化のベストプラクティスとパターンについて解説します。これらは、ちょっとした知識で実行でき、作業を大幅に効率化できるTipsです。シェルスクリプトは、特にUNIX系システムでの自動化タスクに欠かせないツールです。適切に使用すれば、複雑なタスクを効率的に、そして信頼性高く実行できます。 トイルとは、反復的でマニュアルな作業のことを指します。これには、例えば、手動でのシステムのスケーリングや、エラーのトラブルシューティング、ルーティンなメンテナンス作業などが含まれます。トイルを特定し、それを自動化することで、エンジニアはより創造的なタスクやプロジェクトに焦点を合わせることができます。 トイルを判別する方法としては、以下のような基準が挙げられます： 手作業であること 完全な手作業だけでなく、「あるタスクを自動化するためのスクリ

2024-07-09 Platform Engineering Kaigi 2024 https://www.cnia.io/pek2024/

この記事から得られる知識 この記事を読むと、以下を "完全に理解" できます✌️ Istioのサイドカーメッシュを題材にしたEnvoyの設定の抽象化について 様々なサービスメッシュツール (特に、Istio、Consul、Cilium、など) でも流用できるEnvoyの知識について この記事から得られる知識 01. はじめに 02. 様々なリソースによるEnvoy設定の抽象化 サービスメッシュ外からのHTTPS マイクロサービス間のHTTPS サービスメッシュ外へのHTTPS 03. istio-proxyコンテナによるHTTPS処理 Istioコントロールプレーンの仕組み サービスメッシュ外からのHTTPS マイクロサービス間のHTTPS サービスメッシュ外へのHTTPS 04. EnvoyによるHTTPS処理 Envoyの設定の種類 フィルター フィルターの一覧 フィルターチェーンの仕

こんにちは。SRE部プラットフォームSREブロックの高塚です。 6月20日、21日の2日間に渡って幕張メッセで開催されたAWS Summit Japanに、SRE部から10名以上のエンジニアが参加しました。この記事では熱気あふれる会場の様子と面白かったセッションについてご紹介します！ AWS Summit Japanとは 会場の様子 セッションレポート おわりに AWS Summit Japanとは www.youtube.com AWS Summit Japanは延べ3万人以上が参加する日本最大の「AWSを学ぶイベント」です。今年は昨年に引き続き幕張メッセで2日間にわたり開催されました。ライブ配信も行われたほか、2024年7月5日まではオンデマンド配信を視聴できます。 aws.amazon.com ちなみに2023年と2019年以前はAWS Summit Tokyo、2020年から202

メンバーと1on1をしていると、「うっかりミスが多くて Pull Request で毎回コメントをもらってから気づくのを何とかしたい」という相談を受けることがある。 まず、そういう認識を持てていることが素晴らしい。課題意識があるのであれば、どう補正していくかを一緒に考えることができる。 自分がオススメしているやり方は、レビューを依頼する前に徹底的にセルフレビューすることである。巷でよくやられている方法ではあるが、どういうやり方かを雑に書いておく。 レビューを依頼する前に レビュワーになりきって 自分の Pull Request を自分でレビューしてみる 頭にレビュワーが思い浮かぶのであれば、その人を "憑依" させるイメージ 「この人はここでこういうコメントしそうだな」と思ったら、 先回りして PR上にコメントしておくか、突っ込まれないようにコードやコードコメントを改善する タイトルや説明

しばたです。 昨年10月にGoogle(Gmail)および米国Yahoo!においてスパム対策の強化がアナウンスされました。 この件に関してつい先日まで他人事でいたのですが、実は全然他人事では済まないことが発覚し突貫で知識を仕入れています。 アナウンスに対する具体的な対応策についてはこちらのZennの記事を見れば全部わかる感じです。 最高ですね。 また、メール送信にAmazon SESを使っている場合はAWSのブログを確認すると良いでしょう。 「これらの記事を読み解けば万事解決！」という感じではあるのですが、私自身が学んだなかで予め知っておくと良さそうに思えた点がいくつかありました。 本記事ではその辺を共有するのと、実際にAmazon SESの環境を作って動作確認をしたのでその結果も合わせて共有します。 はじめに覚えておくと良い基礎知識 Zennの記事でも詳細な解説がありますが、個人的に「最

公開日 2024/01/23更新日 2024/02/15あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】 ユーザーや顧客へ信頼性を担保した価値提供をしていく中で、監視・オブザーバビリティの取り組みは非常に重要です。 今回の特集記事では、合同会社DMM.com、株式会社MIXI、株式会社マネーフォワード、パイオニア株式会社、Sansan株式会社、株式会社ZOZOの6社の各サービスを支える監視・オブザーバビリティの仕組みとして各社がどのようなアーキテクチャを組んでいるのか、またそのアーキテクチャにしている背景や意図についてお伺いしました。 自社に近いアーキテクチャやどのようにツールを活用しているかについて、実際の事例を元に参考になれば幸いです。 なお、後編も近いうちに公開させていただきますのでお楽しみに。 合同会社DMM.com（DMMブックス） アーキテクチャ設計の背景・意

Amazon Web Services ブログ Yahoo/Gmail におけるメールの一括送信者に求められる要件の変更について この記事は An Overview of Bulk Sender Changes at Yahoo/Gmail (記事公開日: 2024 年 1 月 12 日) を翻訳したものです。 Gmail と Yahoo Mail は、ユーザーの受信トレイを保護するための取り組みとして、2024 年 2 月から送信者に関する新たな要件を発表しました。これらの要件を満たすために Amazon Simple Email Service (Amazon SES) を利用するお客様が具体的に何をすべきかを詳しく見ていきましょう。 新しいメール送信者の要件は何ですか? 新しい要件には、メールボックスプロバイダーへの良好な配信を実現するために、すべてのメール送信者が従うべき長年培われ

以前以下のブログで公開したMac用のdotfilesを色々改良してみたので、改良版として本記事で公開する。 なおdotfilesとは、ホームディレクトリに存在するドット(.)から始まる設定ファイル群の事を指す。 dotfiles の中身 $ tree . ├── .bin │ ├── .Brewfile │ ├── .bash_profile │ ├── .bashrc │ ├── .gitconfig │ ├── .gitignore_global │ ├── brew.sh │ ├── defaults.sh │ ├── init.sh │ └── link.sh ├── .github │ └── workflows │ └── main.yml ├── Makefile ├── README.md ├── chrome │ └── extensions ├── raycast │

はじめに こんにちは。ブランドソリューション開発本部バックエンド部SREブロックの山岡（@ymktmk）です。 11/27〜12/1にラスベガスで開催されたAWS re:Invent 2023に、弊社から7名のエンジニアが参加しました。この記事では現地の様子とセッションについて紹介します！ AWS re:Invent 2023とは 現地の様子 セッション紹介 おわりに AWS re:Invent 2023とは re:InventはAmazon Web Services（AWS）が主催する大規模な技術カンファレンスです。 AWSが提供する様々なクラウドサービスに関する新サービスやアップデートが発表されます。参加者はセッションやワークショップを通じて、最新のクラウド技術に触れることができます。 内容は非常に多岐にわたり、コンピューティング、データベース、人工知能（AI）、機械学習（ML）、セキ

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 突然ですが、みなさんへ質問です。「今この瞬間にシステム障害が起こったら、自信を持って対処できますか？」システム運用者であれば、誰しもが考えたことがある内容かと思います。障害の影響範囲がどの程度なのか、ユーザーアナウンスの必要の有無、そして自動復旧のメカニズムが正しく動いたか。そのあたりが気になるポイントなのではないでしょうか。単純な質問ではありますが、とても考えることが多い不安な質問です。 システムは動いて当たり前と思われがちですが、実際は動いている方が奇跡、壊れて当たり前、という点はエンジニアのみなさんなら共感していただけると思います。どうやったら障害にアプローチできるか、ヤフーで取り組んでいるカオスエンジニアリングについて紹介

はじめに これは、Kubernetesアドベントカレンダー2の20日目の記事です、と思っていたら1の17日目が空いていたのでそっちに移します。 結論 htopはホストのリソースを取得できるカーネルの情報を見に行っているから！ 終 制作・著作 ━━━━━ ⓃⒽⓀ 終わりではない これだけだとアドベントカレンダーの記事としては内容があまりにも薄すぎるのでもうちょっと書きます。 この話を進める前に揃えておくべき前提知識の話。コンテナとVMの違いを説明する方法はいくつかありますが、決定的な違いとしては根本的にリソースの分離の仕方がちがうところにあります（細かいこというのもアレですが、ここではruncなどの標準的なコンテナ実装を用いた場合の話をしています）。 仮想マシンはホストマシンのリソースを（USBやPCIなどをパススルーする場合を除いて）基本的には全て隠蔽し、少ないリソースでデバイスのエミュレ

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、第11/12代黒帯（ヤフー内のスキル任命制度／Webフロントエンド領域）の浜田（@narirow）と、Yahoo!ニュースのエンジニアの喜楽（@gladenjoy）です。今回は、ヤフーで対応をすすめてきた、BFCacheの有効化にむけた取り組みについてお話しします。BFCacheとはそもそも何か、有効化のボトルネックには何があるか、そして調査方法などの具体的な手法などを交えてご紹介します。 ヤフーではこれまでスムーズなユーザー体験を実現するべく、高速にページを表示できるBFCache技術の検証と、BFCacheの有効化率を上げる取り組みを行ってきました。その結果、Yahoo!ニュースでの検証では、PVが+2％向上、広告

はじめに AWS CDK への Pull Request がマージされ、このマージが取り込まれた最新バージョン v2.83.0 がリリースされました。 Pull Request の内容は「autoDeleteImages: true に設定した ECR リポジトリにマルチアーキテクチャコンテナイメージをプッシュした状態で cdk destroy してもリポジトリの削除に失敗する」というものでこちらの issue で報告されていたものです。この記事ではそもそもマルチアーキテクチャのコンテナイメージとは何か、CDK でのバグはなぜ起きたのか、どのように修正したのかを解説します。 マルチアーキテクチャコンテナイメージとは その前に: コンテナイメージとは コンテナイメージはベースイメージにレイヤーが積み重なったものです。例えば Docker の getting started にある例で言うと

本稿は、ZOZO Advent Calendar 2023 シリーズ 6 2日目の記事です。 AWS re:invent 2023に参加してきました。 弊社からは7名が参加し、うち2人は昨年のre:invent2022にも参加したメンバーでした。 私も2回目の参加であり、初参加メンバーの疑問点に答えたりアドバイスをする機会が多々ありました。 会社としての参加ブログは別途投稿されますが、今回はre:inventに関して社内で一緒に参加したメンバーにしたアドバイスや個人的に知っておいたほうがいいと感じた内容をまとめます。 なにも知らない状態でre:inventに参加すると知らないワードがいろいろ出てきたりとハードルが高いので、もし参加する機会があればこの記事を参考にしてもらえればと思います。 この記事はre:invnentに参加するまでの工程すべてを網羅しているわけではないです。 要所要所で使

こんにちは。SRE部の巣立（@ksudate）です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。 本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプライン GitHub Environmentsによるリリー

Amazon Web Services ブログ Amazon ElastiCache for Redis でリアルタイムゲームリーダーボードを構築する ゲームリーダーボードを使用すると、プレイヤーは互いのパフォーマンスを比較できます。この重要なソーシャル機能により、プレイヤーの関わり合いが高められ、競争が促進されます。リーダーボードのデータは、同様のスキルレベルの競争相手とプレイヤーをマッチングさせるゲーム内のアルゴリズムに活かすこともできます。 この記事では、伝統的なリレーショナルデータベースを使用してゲームリーダーボードを構築および拡張することに関する課題を探ります。また、Redis などの最新のインメモリデータストアを活用して、非常に効率的でスケーラブルなソリューションを提供する方法についても検討します。 この提案されたソリューションは、リーダーボードストレージとクエリをリレーショナ

GitHub ActionsからAWSを操作できると便利です。OIDC（OpenID Connect）を使えばアクセスキーも不要で、セキュアに運用できます。しかし複数システムにまたがる特性上、トラブルシューティングは面倒です。そこで本記事ではトレーサビリティを向上させ、メンテナンスしやすくする手法を紹介します。トレーサビリティが向上すれば、運用はもっと楽になります。 GitHub ActionsとAWSは赤の他人 当たり前ですが、GitHub ActionsとAWSはまったく異なるシステムです。何を言っているんだという感じですが、トレーサビリティの観点では重要です。なぜなら複数のシステムを扱うときは、トレースできるよう設計しないとトレーサビリティは生まれないからです。 GitHub ActionsやAWSに限らず、普通は他所様のシステムなど知ったこっちゃありません。このお互いに知らんぷりを