概念図 とりあえずECSに出てくるエンティティがそれぞれどんな多重度で関連しているのかをまとめてみました。ここからはそれぞれのエンティがどんな概念なのかを解きほぐしていきたいと思います。 図1 概念図 Serviceが中心 ECSは平たく言うと クラスター（＝複数EC2インスタンスの集合）の上で Dockerコンテナを使って、 Serviceを動作させる ものです。 図2 例えばの構成 上図は、 Front Service (裏にいるAPIをCallしてWEB UIを提供するもの） API Service （ビジネスロジック、DBへの読み書きをRESTful APIで提供するもの） と言う２つのService で構成されるWEBアプリケーションの例です。 ECSで言うServiceは、Serviceは利用者から見た「サービス」よりも一段階か二段階細かいもので、APIサーバーとか、フロントサ

社で必要になったので、Go 言語の OSS を書きました。 github.com この OSS がなんなのかは スライド を見ていただくとして、テストをめっちゃ書いたのでだんだんどうテストを書いたらやりやすいのかがわかってきました。この成果自体はいつか vanilla-manifesto へまとめると思いますが、簡単に説明しようと思います。 書いてて辛くないテストをするために、もっとも重要なのは テスト対象の設計 です。設計といえば、よく SOLID がよいオブジェクト指向設計の指針とされますが、テストの文脈でも同じことがあてはまります。例えば、テスト対象が SOLID をよく守っていると次のように嬉しいことがあります： 単一責任原則 (S) これが守られると、どんな振る舞いを検証したいのかが明確になるので読みやすいテストになる 開放閉鎖原則 (O) これが守られると、機能の追加/変更でテ

ECSのスケーリング戦略を柔軟に設定でき、さらにFargate Spotを活用できるCapacity Provider、皆さんすでにお使いでしょうか？ re:Invent2019の開催中に突如発表された新機能なのですが、「Fargate Spotとかいうのが使えるらしいで！」というキャッチーな側面はありつつも、その概念はECS全体を包括するもので、正直自分も最初とっかかりが難しかったです。 この記事は、CM re:Growth 2019 TOKYOで発表した内容を元に、Capacity Providerの全体像を掴んでもらうことを目的に書きました。ECSにおけるかなり大きな機能拡張なので、普段からECSを使われている方は、是非この記事でこの新機能を掴んでもらえればと思います。 （祭） ∧ ∧ Y　 ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉     Capacity Provider ﾏﾂﾘﾀﾞﾜ

こんにちは。宿泊事業本部の宇都宮です。この記事では、GraphQLをベースに、GoとTypeScriptでスキーマを共有しながら開発を進める方法について紹介します。 この記事は 一休.com Advent Calendar 2019 の16日目の記事です。 GraphQLとは ライブラリの選定 コードファースト vs スキーマファースト Goによるサーバ実装 TypeScriptによるクライアント実装 おわりに 参考文献 GraphQLとは GraphQLは、Facebookによって開発された、Web APIのための クエリ言語 です。その特徴もSQLに似ていて、データの取得や更新を宣言的な記述によって行うことが出来ます。 仕様は公開されており、リファレンス実装として graphql-js がありますが、それ以外にも様々な言語でGraphQLサーバを実装できます。 GraphQLでは以下の

この記事は Wano Group Advent Calendar 2019 の7目の記事となります。 アドベントカレンダーに「なにか」書くといって7日を予約していたんですが、特にネタを考えてなかったら、前日にネタが降ってきたという話です。 ※後日談を追加しました(2019/12/15) 始まりは経理担当者のSさんの指摘 ちょうど昨日(12/06)のことです。経理担当者のSさんに「Google Cloud Service から38,653円がクレジットカードの明細にあるのですが、証憑がないんですが…」と相談を受けました。月初は会社に対する請求の確認作業があり、請求書がない引き落としとかは問題になりますので、たまに確認されることがあります。 新しくサービスを開始する際に、AWSやGCPとか有料サービスのアカウントを新しく作る必要があったりすると、そんなことが起きたりします。要は経理担当にメール

ご挨拶 初めまして @moriya-snj です。 この記事は「本番環境でやらかしちゃった人 Advent Calendar 2019 - Qiita」の15日目の記事です。 みなさん盛大にやらかしている様で安心しております。 今回は私が社会人3ヶ月目でやらかした重大事故の記録を包み隠さず暴露するとともに当時フォローしてくださった先輩や上司お陰でなんとかこの業界で生き抜くこと出来ていることの感謝をお伝えすべく、キーボードに手を伸ばしております。 何をしでかしたか 顧客AがIP電話を導入するため、新たにVoIP用ネットワークを構築することとなった。 機器の設置等は別部署が行うため、設置依頼を出し、完了の報告をもらったため、ネットワーク機器のコンフィグなどを流し込み疎通確認などを行うこととなった。 疎通確認が完了し、お次はVRRPの切替確認を行おうとしたが、ここで誤って稼働中の顧客Bのネットワ

君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、

技術書典7で頒布したAWS本です。 ■ 本書の目的 本書はIAMの機能に絞って解説するという機能特化本です。 筆者は今まで、商業誌で「AWSの基本機能」、「サーバレス」、「業務システム」、「試験対策」をテーマに4冊のAWS本を書きました。 テーマに沿って必要な機能を紹介していくというスタイルだったのですが、今回は逆に機能を元に解説するというスタイルに挑戦しています。 それでなぜ、IAMなのでしょうか？AWSが不正利用されて100万円の請求が来たというようなニュースを、ネットで時々目にする事があります。原因の多くがIAMのアクセスキーをGitHubに誤ってコミットしてしまい、そのキーを不正利用されたケースです。そういった事態を防ぐために正しくIAMを知って貰いたいのです。 IAMは、AWSの利用権限を管理する極めて重要な機能です。AWSには多種多様な機能があり、IAMはそれに応じて様々な記述

ブロックチェーンの応用については「実証実験どまり」「実用化はまだ先」という意見を依然として耳にする一方、実用化局面の実例が数多く公知のものになってきている。今回は、2019年1月から11月を振り返り、実用・商用レベルで世に出た取り組みについて概観したい。 まず、PS（Programmable Securities）分野から見てみよう。世界銀行が、２度目のブロックチェーン債を発行し5千万豪ドルを調達した他、HSBCが紙上で管理されていた200億$の資産をブロックチェーンカストディ上で管理していくことを発表した。中国の大手商銀である中国銀行は、中小事業者支援を目的とした2800億円規模のブロックチェーン社債を発行しており、スペインSantander銀行もPublic Etherum上で社債を2000万$分発行。また、プラットフォーム面でも、14の大手商業銀行が参加するFnalityプロジェクト

この記事はCamphor- Advent Calendar 2019 15日目の記事です。 Squelette: Yet another TS codegen ecosystem for Open API. Embedded content: https://github.com/andoshin11/squelette 本Advent Calendarへの参加も今年で4回を数えます。フロントエンドなAndyです。 ここ数年の間に加速度的にTypeScriptの利用機会が増え、Webブラウザで動くSingle Page Applicationの世界にも静的型付けの考え方が浸透してきました。 Redux, VuexのようなRepositoryレイヤーからUIコンポーネント内のビジネスロジック、ひいてはDOMにいたるまで一気通貫に型の恩恵を感じることのできる開発体験は、今後もしばらくメイントレ

個人的な感触ですが、ECSとEKSを並べてみた場合、ものすごい単純に以下の感想でした。 「できることはEKSのほうが多い。けど、そのぶん習得がECSより難しい」 よく考えるとこの「難しい」という単語、簡単に使ってしまいがちなんですが使い方を間違えると非常に危険な言葉だとも思ってます。それは「誰にとっての難易度か？」という観点が抜け落ちがちだから。 AWSにおいてコンテナワークロードを展開しようと検討する人は様々いると思いますし、その組織や担当者の技術スタックも千差万別でしょう。kubernetesの経験は豊富だけれどAWSの経験はあんまりない、またはその逆、もしくはDockerは散々さわっているけれど、オーケストレーションツール自体が初めての人など。 自分の現場経験はECSのほうがEKSより圧倒的に多く、今でも「EKSってやっぱりなんか敷居高いなぁ」と感じてます。でも、よくよく思い出すと最

こんにちは！技術部の小池です。 この記事は Tech Kayac Advent Calendar 15日目の記事です。気付いたらもう12月も半分じゃないですか…もう今年の営業は終わりにしてお酒飲んで年越しを迎えたい気分ですね〜。 今回はマルチテナントなサービスにおける認証と権限管理についてのお話です。 要件 今回お話するサービスはカヤックグループ全体に提供する予定のマルチテナントのサービスです。カヤックの文化を支える 360度フィードバック、スマイル給 などの複数のサービスが協調して動作するというサービス指向的なアーキテクチャで、既存のカヤック社内サービス群のリニューアルプロジェクトでもあります。 カヤックグループ向けに提供するサービスなので、認証をしないことには利用することはできません。また、カヤックの社員が他のグループ会社の情報を見れてしまうというのも困ったことになってしまうので、組織