サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
災害への備え
sreake.com
1. はじめに こんにちは、「信頼性は可用性ではない」を標語にしているnwiizoです。 近年、サービスの信頼性向上に向けた取り組みとして、SLI(Service Level Indicator)、SLO(Service Level Objective)、エラーバジェットという概念が注目を集めています。これらは、Google発祥のSRE(Site Reliability Engineering)プラクティスの中核をなす考え方であり、多くの組織がこのアプローチを採用し始めています。また、関連するツールも成熟し始めており、実践的な導入がより容易になってきています。 本ガイドでは、SLI、SLO、エラーバジェットを導入する前に知っておくべき重要なポイントについて詳細に解説します。各概念の定義から実践的な導入ステップ、さらには組織文化の変革まで、包括的な情報を提供します。 2. SREにおける基本
はじめに こんにちは、皆さん。今日は、シェルスクリプトを使った高度な自動化のベストプラクティスとパターンについて解説します。これらは、ちょっとした知識で実行でき、作業を大幅に効率化できるTipsです。シェルスクリプトは、特にUNIX系システムでの自動化タスクに欠かせないツールです。適切に使用すれば、複雑なタスクを効率的に、そして信頼性高く実行できます。 トイルとは、反復的でマニュアルな作業のことを指します。これには、例えば、手動でのシステムのスケーリングや、エラーのトラブルシューティング、ルーティンなメンテナンス作業などが含まれます。トイルを特定し、それを自動化することで、エンジニアはより創造的なタスクやプロジェクトに焦点を合わせることができます。 トイルを判別する方法としては、以下のような基準が挙げられます: 手作業であること 完全な手作業だけでなく、「あるタスクを自動化するためのスクリ
はじめに こんにちは、最近の私の人生はキックボクシングとコーディングの2つの活動に極端に偏りつつあります。nwiizoです。一見正反対のようなこの2つの活動ですが、共通する本質があります。それは、頭で考えるだけでなく、実際に体を動かして実践することで新しい発見や気づきを得ていくプロセスです。 キックボクシングでは、理論だけでは表現できない”技”を体で覚えていきます。理論上の動作はスムーズに行えても、実際にパンチやキックを繰り出す際には、さまざまな戦略を一瞬のうちに計算し、機動的に対応しなければなりません。そこでは思考するよりも先に、体が自然と反応するよう繰り返し訓練を重ねていきます。 一方のコーディングにおいても、書籍から得た知識を単に暗記しているだけでは意味がありません。実際にコードを書きながら、試行錯誤を重ね、バグに出くわし、その都度解決策を見出していく中で、本当の理解が深まっていきま
はじめに プラットフォームエンジニアリング(Platform Engineering)とサイト信頼性エンジニアリング(SRE, Site Reliability Engineering)はともに、ITインフラとアプリケーションの運用に関わる分野ですが、それぞれに独自の焦点とアプローチがあります。 Gartnerの報告によれば、Platform Engineeringは、自動化と開発者の経験を中心に据え、アプリケーションのデリバリーを迅速化し、ビジネス価値を効率よく生成することを目的としています。 この手法は、製品チームが顧客に対して価値をより速やかに提供することを前提としています。 参考資料: What Is Platform Engineering? What Team Structure is Right for DevOps to Flourish? 道を照らす: プラットフォーム
はじめに こんにちは!Sreake事業部 志羅山です。今年3月に3-shakeに入社し、長野県からリモートで仕事をしています(東京にも定期的に行ってます)。 最近、とあるお客様環境におけるECS(AWSのフルマネージド型コンテナオーケストレーションサービス)の利用方針を整備する中で、ECSの可用性に関する設計要素について調査・整理する機会がありました。今回この記事ではその内容を紹介したいと思います。 整理してみて感じたこととして、「思ったよりも考えることが多く、やや複雑で奥深い」という印象を受けました。同じように感じている方にとって参考になれば幸いです。 当記事の目的と書くこと この記事は「ECSの可用性に関する設計要素や考慮事項の体系がややぼんやりしている」という読者の方に「全体のイメージが何となくつかめた」と感じてもらえることを目的としています。 そのために、「ECSの可用性設計要素」
はじめに OpenSLO の概要に触れながら SLO as Code の現状についてお話しします。 OpenSLOとは? OpenSLO とは、サービスレベル目標 (SLO)、それに関連するリソースの記述形式を標準化する試みです。 SLO の SaaS を展開している Nobl9 が中心となって策定し、2021年5月にバージョン 1.0 を発表しました。 SLO をコードで扱うツールは以前からありましたが、SLO のデータ表現方法が確立されていなかった中、OpenSLO が発表されました。 リポジトリ https://github.com/OpenSLO/OpenSLO OpenSLO の特徴 Kubernetes YAML フォーマットで記述し、リソースとして以下が定義可能です。 DataSourceSLOSLIAlertPolicyAlertConditionAlertNotifica
1. はじめに はじめまして、Sreake事業部インターン生の井上です。私はSreake事業部にてSRE技術の調査と研究を行う目的で2023年3月6日から長期インターン生として参加しています。 本記事では、Kubernetesの運用効率化をChatGPTで実現する方法について調査・評価した事をまとめました。 2. ChatGPT-3とは? 概要 開発元のOpenAI 公式からの引用会話形式でやり取りする ChatGPT というモデルをトレーニングしました。対話形式により、ChatGPT はフォローアップの質問に答えたり、間違いを認めたり、間違った前提に異議を唱えたり、不適切な要求を拒否したりできます。要約すると、対話形式で会話ができるチャットボット。GPTとはGenerative Pre-trained Transformerの略で、Transformerと呼ばれるニューラルネットワークア
今回は Chaos Mesh を紹介します。 Chaos Mesh は Kubernetes 環境向けの Chaos Engineering ツールです。 Chaos Mesh によるカオスエンジニアリング Sreake の寺岡です。今回は Chaos Mesh を紹介します。 Chaos Mesh は Kubernetes 環境向けの Chaos Engineering ツールです。 カオスエンジニアリングの原則 カオスエンジニアリングと言えば本番環境で発生しうる Node 障害を日常のものにするということが元々の目的だったのではないかと思いますが、今日では意図的に障害を発生させること全般が対象となっているように感じます。まれに発生するトラブルを開発環境で意図的に発生させてコードの品質を上げるということが含まれてきているようです。 ここで紹介する Chaos Mesh も、開発元である
Available libs K6 は Javascript を用いて負荷試験のテストを実施するのですが、Golang の内部で CMAScript 2015+(ES6+)を実行しています。 K6 は NodeJS でも、ブラウザーでもありません。 NodeJS によって提供される API に依存するパッケージ、たとえば os と fs モジュールは K6 では機能しません。 その為、データ加工などのモジュールを提供しているのがこれらです。 https://k6.io/docs/javascript-api/jslib/utils/ ※ CMAScript 2015+(ES6+)に準拠しない記述を意識する必要はありません。 k6-jslib-aws が登場だが gcp 版はない https://github.com/grafana/k6-jslib-aws k6-jslib-aws では
はじめに はじめまして、スリーシェイクのSreake 事業部インターン生の鈴木友也と永井隆介です。Sreake 事業部は SRE関連技術に強みを持つエンジニアによるコンサルテーションサービスを提供する事業部であり、私たちも SRE 技術の調査と研究を行う目的で2022年10月11日 ~ 24日に開催された短期インターンに参加しました。2週間という期間を使って、Trivy Operator の技術検証と運用方法の提案を行いました。以下では、その成果をまとめたいと思います。 Trivy Operatorとは Trivy Operatorは、Kubernetes ネイティブな統合セキュリティプラットフォームです。具体的には、Kubernetes Operator を用いてコンテナイメージの脆弱性を自動でスキャンしたり、デプロイされる Kubernetes リソースの設定不備を自動で検証したりでき
Terratest の概要 公式HP: https://terratest.gruntwork.io/ Githubリポジトリ: https://github.com/gruntwork-io/terratest インフラコードに対してテストを書くオープンソースの Go ライブラリで、以下に対応しています。 TerraformDockerPackerkubernetes 開発元は Gruntwork です。 パッケージと概要 aws: AWS API を使った機能を提供 ・EC2 インスタンスの IP を取得 ・リージョンと VPC ID を指定して、含まれているサブネット情報を取得collections: Slice や string に対してのいくつかの機能を提供 ・指定の Slice に指定の文字列が含まれているかどうかを確認docker: docker コマンド、docker-co
SREにおいてポストモーテムの文化を根付かせることは必要不可欠です。 ポストモーテムはSREの導入効果をより高め、結果としてシステムの信頼性向上に繋がる体制が作れます。 本記事では、良いポストモーテムの形成方法について解説します。ポストモーテムの作り方で悩んでいる担当者の方、SRE導入を検討している方は最後までお付き合いください。 ポストモーテムの必要性とメリット良いポストモーテムを執筆するために必要な5つのポイントポストモーテム文化を根付かせるための施策ポストモーテム文化およびSRE組織の形成ならお任せください ポストモーテムの必要性とメリット ポストモーテム(post mortem) は「事後」を意味し、SREにおいては「失敗から学び、同じ過ちを繰り返さないこと」に重点を置いた考え方になります。 サービス運用において障害や失敗が発生した後、「ひとまず問題は解決したし、収束したからOK」
ITサービスのインフラ運用・改善といった観点から「SRE」という言葉を耳にすることが増えてきました。以下では、SREとは何か、DevOpsやインフラエンジニアと何が違うか、どのような場面でSREが必要になるかといった点について解説いたします。また、「SREに関するTips」や「ITサービス企業の自社SRE事例」についても、あわせてご紹介します。 SREとはなにか SREとは、ITサービスの信頼性を高めるために、ITエンジニア(開発者)が信頼性向上のために行う設計やアプローチ、またはこれらを行うチームを指します。 SREの発端は、グーグルが自社の検索エンジンサイトである「google.com」を安定稼働させるために、システムアドミニストレータ(運用者)ではなく、エンジニアを用いてサービス横断的なアプローチに実施したアプローチを指します。なお、サイトリライアビリティエンジニアリング(Site
この記事では、SREとインフラエンジニアの違いについて3つのポイントで解説します。 SREとインフラエンジニアの違いを3つのポイントで理解する SREとインフラエンジニアの3つの違い1.業務範囲2.スキルセット3.方法論インフラエンジニアのキャリアパスとしてのSRE希少なSRE人材が提供する高品質なSREサービス = Sreake ここ数年、国内外問わずSREという職種が注目されてきており、実際にSREチームを作ってサービスを開発している企業も増えてきました。しかし、実情を見ると、従来のインフラエンジニアチームと大きな違いはなく、SREとしての力が十分に発揮されていないことが多いように感じます。 そこで今回はSREとインフラエンジニアの違いについて解説していきます。SREとインフラエンジニアの作業領域や、根本となる考え方の違いについても触れていきます。 関連記事:「SREとDevOpsの違
SREとDevOpsの違いDevOpsとはSREとはDevOpsの実装としてのSRE継続的な改善の必要性組織を超えたコラボレーション変更管理と自動化計測の重要性非難のない文化開発速度の改善SREのことなら弊社にお任せください Webサービスの信頼性や価値の向上に用いられるアプローチ方法としてSRE(Site Reliability Engineering)というものがあります。システム開発側と運用側の溝を埋めるために生まれたこの手法ですが、従来のDevOpsとはどのような違いがあるのでしょうか。 本記事ではSREとDevOpsの違いについて見ていきます。 関連記事:「SREとインフラエンジニアの違いについて」 SREとDevOpsの違い SREとDevOpsの違いや関係性を知るには、Googleが提唱している「class SRE implements DevOps」の考えが最も明解でしょう
現時点(2021年6月17日)では英語でも日本語でもそれほど情報がないGoogleが開発したSIEM(Security Information and Event Management)製品である「Chronicle」に関して、お伝えしていきたいと思います。 謎のベールに包まれたGoogleの次世代SIEM「Chronicle」を触ってみた こんにちは、堤@スリーシェイクです。 本日は、現時点(2021年6月17日)では英語でも日本語でもそれほど情報がないGoogleが開発したSIEM(Security Information and Event Management)製品である「Chronicle」に関して、お伝えしていきたいと思います。 Chronicleの特徴 データ容量やサーバ台数に依存しない課金モデルGoogleのインフラをフル活用した驚異的な検索速度と相関的なログ分析シンプルな
私たちはSREの プロフェッショナル パートナーです Sreake(スリーク)は、金融・医療・動画配信・AI・ゲームなど、 技術力が求められる領域で豊富な経験を持つ SREの専門家が集まったチームです。 戦略策定から設計・構築・運用、SaaS提供まで、幅広い領域をサポートします。
このページを最初にブックマークしてみませんか?
『SRE構築総合支援サービスSreake | 株式会社スリーシェイク』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く