Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。Kwiatkowski氏がベルリンのVelocityカンファレンスで講演して、ShopifyがKubernetesのカスタムオートスケーラ(autoscaler)を開発した理由について説明した。既存の自動スケールソリューションがShopifyのニーズを満足しなかった大きな理由は、同社に流入する巨大かつ急激なトラフィック要求にある。同社は、スケールダウン時や複雑なスケール条件におけるコスト効率の高いソリューションも必要としていた。Kwiatkowski氏によれば、ShopifyのWebサイトでは、特にセールスキャンペーンや"フラッシュセール"時に大規模かつ急激なリクエストが発生する。フラッシュセールとは、通常は15分から20分といった短時間に行われるセールである。従って、高速なスケールアップが必要になる。新たなノードのスピンアップやDockerイメージのダウンロード、デーモンセットなどのアプリケーションの起動といったアクティビティを持つリアクティブなスケーリングは、同社では役に立たない。スケールアップに平均20~25分も要するようでは、自動スケールアップが完了してキャパシティが増大した頃には、フラッシュセールは終わっているかも知れないのだ。スパイク的なトラフィックに対応するため、Shopifyでは、Goを使ったカスタムオートスケーラを開発した。現時点ではオープンソース公開はされていない。合わせて同社には、安全なデプロイメントを行うためのコントロールや、過去データを使用するような複雑なスケール条件の設定を行う必要もあった。同社のオートスケーラは30秒毎に起動し、次のフラッシュセールに必要なレプリカを追加する。スケールアップとスケールダウンは月毎のクラウド費用にも影響するため、オートスケーラはそのために有用な判断を行う必要がある。そこで、クラスタに必要なレプリカ数を決定するためにShopifyは、KubernetesのHPAから流用したリスク対コスト分析の公式を使用している。サーバをどの程度ビジーにしたいかを定義する。その上で、サーバのビジー状態と存在するレプリカ数に基づいて、クラスタの所持すべきレプリカ数を公式から導き出すのだ。設定したクラスタの利用度を常に維持することが、この方法の目標である。クラスタのスケールダウンには時間を要するため、コスト増加の原因となる。従って、コスト効率のよいスケールソリューションを実現するには、過去のトラフィックデータの分析によるオートスケーラの改善が必要だ。何回かの経験を通じて、Spotifyでは、一般的なソリューションが行っているような平均CPU使用率を使用したスケーリングルールの設定では、スパイクを正確に予想できないことに気付いた。CPU使用率の中心値(median)を使用した方が、一時的な容量増に対して良い結果が得られたのだ。長時間(30分間)のスパイクに対しては、レプリカが追加されないという問題がある。これを解決するために、CPU使用率として指数加重平均(EWA)を使用して、古い値よりも新しい値をより重要視することで、より多くのレプリカが短時間に追加されるようにした。Shopifyのオートスケーラでは、CPU使用率の中央値とEWAの両方を計算して、大きな差異がなければ中央値を使用し、そうでなければEWAを使用するようになっている。この方法で、必要な時に、必要なだけのレプリカを追加するようになる。最後にKwiatkowski氏は、収集データにヌル値やゼロ値、旧値や欠測といったエラーが発生した場合について話した。スケールアップおよびダウン時の問題を回避するため、このようなデータエラーが発生した場合、同社では、安全を考えて常に最大容量にスケールするようにしている。同時に、スケールダウン時の問題を回避するため、最小にレプリカ値の設定も行っている。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。