トリプル・ダブリュー・ジャパン(DFree)開発者ブログスマートフォン用の表示で見るトリプル・ダブリュー・ジャパン(DFree)開発者ブログ排尿予測デバイスDFreeを開発しているトリプル・ダブリュー・ジャパンの開発者ブログですこの広告は、90日以上更新していないブログに表示しています。2019-09-042019/08/23のAWS大規模障害が40秒のAPIエラーで済んだ理由トリプル・ダブリュー・ジャパン株式会社でソフトウェアアーキテクトをしています西田です。ネット上では主にkbigwheelの名前で活動しています。この記事では先日のAWS大規模障害がトリプル・ダブリュー・ジャパンのシステムへどのような影響を与えたのか、またそれに絡めて監視・アラートのフローやシステム設計について紹介します。AWS大規模障害2019/08/23の午後、AWSの東京リージョンのEC2およびRDSにおいて大規模な障害が発生しました。(AP-NORTHEAST-1)トリプル・ダブリュー・ジャパンではDFreeサービスでAWSを利用しており、影響が懸念されたのですが幸いにも40秒程度APIがエラーを返す程度で済みました。Logsからエラー原因がDBとのコネクションにあること、その後DBがフェイルオーバーしていることを確認たまたま障害発生の瞬間にエンジニア(私)がslackを見ていたため、問題が発生した瞬間から障害対応と問題原因の調査をすることができました。結果、8分ほどでDBのフェイルオーバーが発生していることを突き止めています。迅速に障害の発生を感知し、原因調査ができたのは監視・アラートのフローがきちんと設定されていたためでした。DFreeサービスでは監視やアラートについては現在slackの特定チャンネルへ集約するポリシーを取っています。lambdaと非常に手間でした)。クリティカルなアラートとそれ以外のアラートを別々のslackチャンネルへ分けていたため、今回即座に重大な問題だと判断することができました。障害発生の時間が40秒で済んだのかDFreeサービスが利用しているAWSの構成DFreeサービスは以下のAWSサービスから構成されています。KinesisS3DynamoDBLambdaSNSALBECSRDS私達のチームではリージョン内レベルでの冗長化を基本のポリシーとしています。ECSでは適切にヘルスチェックとクラスタの最低保証台数を設定することでこれもまた復元をAWSへ任せていました。RDSについてもMultiAZ設定を有効にすることで2つのリージョンで冗長化しています。Zoneにまたがる冗長化を行っていました。冒頭のAWSのレポートにも書かれていますが、今回の大規模障害は東京リージョンの2つのAZのうち1つのAZでのみ発生する障害であったため、DFreeサービスでは最小限の影響で済んだと言えます。ポイント今回の大規模障害とDFreeサービスでの対応からいくつかのポイントを挙げます。14:432019/08/23のAWS大規模障害が40秒のAPIエラーで済んだ理由Tweet広告を非表示にするもっと読むコメントを書く2019-06-24OneLoginとRedashのSAML連携方法トリプル・ダブリュー・ジャパン株式会社でソフトウェアアーキテクトをしています西田です。ネット上では主にkbigwheelの名前で活動しています。最近社内ではredashの重要性が増しており、同時にアカウント管理のコストが徐々に増えてきました。社内ではIDaaSとしてOneLoginが導入されており、redashとのSAML連携ができる環境ができていたのですが一方でSAML連携を一から設定することは難易度が高く、過去複数人が何度か設定に挑戦したものの今まで正しく設定できたことがありませんでした。今回改めて時間を取って問題解決を図ったところ、どうすれば正しく連携できるかがわかりましたのでこちらで手順を残しておきます。以下の環境で作業を行いました。以下のテストのため、自分自身のユーザーへ1で作成したAppの実行権限を付与します(付与方法は直接/Role経由/Group経由などどれでも良いです)。付与したあとにoneloginのポータルに表示されていることを確認すると確実です。Errorが発生しました。以下の手順はredashサーバのエラーログから特定した問題の解決法になります。サイボウズエンジニアのブログにも書かれている通りredashは認証応答メッセージ(Response)のSAMLアサーションの属性ステートメント(AttributeStatement)に、"FirstName"と"LastName"が含まれていることを期待しているです。OneLoginはこのパラメータへユーザーごとに別の値を設定する仕組みを提供していますが、今回は動作確認のため私のFirstName/LastNameをそのまま固定値で書きました。login」ボタンを押したところ、正常にログインすることができました。設計トリプル・ダブリュー・ジャパン株式会社でソフトウェアアーキテクトをしています西田です。ネット上では主にkbigwheelの名前で活動しています。今回は最近私達のチームで行ったRFC7807に沿ったエラーレスポンスの実践について紹介します。APIのエラーレスポンス形式*1です。日本語の解説記事は非常に少ないですが、こちらのブログで非常にわかりやすく要所を日本語に翻訳しつつ説明されています。APIの詳細なエラー情報をレスポンスに持たせるための仕様この標準に沿うことで新しい開発メンバーへ仕様を共有することが簡単になります。過去にこの仕様を見たことがあれば、新たに勉強することは最小限で済みます。サーバサイドチームの取り組み私が所属するサーバサイドチームでは11月にAPIサービスの大幅なバージョンアップを行いました。エラーレスポンスの仕様(特にレスポンスボディの仕様)が曖昧なままでアプリチームがハンドリングしたい粒度でエラー原因を返せていませんでした。そこでエラーケースを再定義するとともにアプリがハンドリングするために必要十分な情報を持たせるよう改修を行うことになったのですが、どうせエラーレスポンス仕様を変更するならより標準的なフォーマットに寄せたいと考えた結果採用したのがRFC7807です。仕様定義RFC7807が定義する仕様にはいくつかの選択肢があります。レスポンスフォーマットをJSONとXMLのどちらにするか、いくつかあるプロパティのうちどれを利用するか、などです。wiki上のページへ以下のようにまとめました(実際のエラーコード・URLとは変更しています)。上に書かれていますが基本的に以下のように仕様を定めました。titleのみを利用する。それらのプロパティは必須であり、レスポンスによって特定のプロパティが欠けるようなことはない。Specificationで書かれてswagger-uiからいつでも参照できるようになっています。こちらには各APIごとのエラーレスポンスの仕様が細かく書かれていましたので、こちらも合わせて修正しました。エラーレスポンス仕様例この仕様決定とドキュメントの作成・更新に比較的時間がかかり、だいたい合計5人日ぐらいかかったイメージです。実装についてAPIサーバはScala言語で書かれておりakka-httpフレームワークで作られています。今までもRFC7807準拠ではなかったもののJSONフォーマットでエラーレスポンスを返していたので、だいたい実装期間は3人日程度でした。リリースについて修正内容に既存のAPI利用を阻害するような破壊的な内容がなかったため、通常通りのリリース手順でリリースしました。API利用側の反応2019/02/01現在アプリ側で増強されたエラーレスポンス情報を利用するコードが書かれておらず、まだフィードバックは特段ない状態です。Qiita)各種WebフレームワークのRFC7807サポートもほとんどない状態ですが、個人の嗜好や趣味によって行き当たりばったりに決めるよりRFC準拠で実装することは様々なメリットがあります。毎回APIの仕様を決めるときは数ある選択肢からどういったものにするか非常に悩むのですが、今回RFCという明確な指針に従ったことで非常に楽に仕様を決めることができました。今回決めた仕様は将来もっと良いものに拡張する可能性もありますが、今回はこちらでリリースしています。各フレームワークも徐々にRFC7807をサポートしつつあるので導入はこれからもっと楽になると思います。トリプル・ダブリュー・ジャパン株式会社でサーバサイドリードエンジニアをしています西田です。ネット上では主にkbigwheelの名前で活動しています。先日、私達の会社でもフル活用しているAWSの新機能・新サービスを発表するre:inventというイベントがありました。reinvent.awseventsjapan.comこちらの記事では発表された中から社内で活用できそうなものをリストアップしたいと思います。アップデートの一覧は以下の公式ブログの記事からいただきました。Blog非常に良いアップデートです。logsは検索機能に癖があることが問題で、そのためにログをS3へ移してathenaで検索などの回避策すら取っていました。logsへ載せて検索することがスタンダードになるかもしれません。Blogこれも素晴らしいアップデートですが、一方で乱用すると本来のパフォーマンスを発揮できなくなる気がします。UpdatedItemでアトミックな操作は従来もできていたので、なるべく最低限の利用に留めるのがいい気がします。CodeDeployの統合がより進みました。PipelineとECRの結合は実は社内ですでに利用していますが、微妙な問題はありつつも基本的にはデプロイフローが非常にスッキリしていい感じです。ブログ大きな可能性を感じるプロダクトです。InfluxDBなどと同様に時間に最適化した操作・演算ができます。事前のキャパシティプランニングが不要のリクエスト課金が可能になりました。ブログ負荷を計算せず開始できるため非常に有用ですが、一方で負荷が一定で安定している場合はリザーブドキャパシティのほうが安くなるそうです。これも割と待望の機能。今までLambdaとALBは連携できなかったので認証をかけるときに不便だったのですがこれによりALBの認証機能が使えるようになりました。Socketコネクションの維持はできないはず。使い方が制限されているかもしれません。ご紹介マイクロサービス的な設計をしているシステムでは待望の機能だと思います。紹介サービスディスカバリのAWSマネージドサービス。ブログ非常に捉え方が難しいサービスだと思います。使えるLayerの数に最大5個の上限があることからも、ライブラリをなんでもlayer化すればいいというものではなさそう。依存性解決・ライブラリのダウンロード・展開などは従来どおりnodejsやpipなどを利用したほうが良いと思います。従来のx86系と比べてコストパフォーマンスが良いそうです。Organizationとその他を統合してより一括して管理できるようにしたもののイメージ。セッション内の説明ではすでに導入済みのAWSアカウントに対して適用するのは難しいという話もあったので、アカウントを作り直したほうがよいかも覚えておきたいものIoT系IoT系の機能追加は非常に多かったです。セッション内でもいくつもおおっと思わせる機能があったのですが基礎知識がないこともありすべてを理解することはできませんでした。以下には公式のアップデート記事があるものを載せます。ワークロードの一時停止と再開が可能にいわゆるハイバネーションです。Linux限定、かつrootパーティションを暗号化する必要があるなどいくつか制約があるそうなので注意が必要そう。Architectedは数年前からAWSが提唱しているキーワードでAWS上での良い設計の指針を定めたものです。AWS上にはすでにいくつも同様のLint系サービスがあり、どれを継続的に利用するべきか迷うところです。Architectedやりたいと思ったときにはこれを思い出しましょう。ブログ普通に、しかしものすごく便利です。ftpが使えないからとS3を使えていなかった層をついにAWSマネージドサービスだけで取り込めます。外部からの素材の納入をこれで受けれそう。ManagementS3上の大量のデータに対して一括処理を書けたいときに有用ですが、そもそもなるべくそういった処理がいらないようなデータのパイプラインを設計したいところ。トリプル・ダブリュー・ジャパン株式会社でサーバサイドリードエンジニアをしています西田です。ネット上では主にkbigwheelの名前で活動しています。本日業務の一貫としてこちらのイベントに参加してきました。aws.amazon.comその中からおそらくキーノートに相当する午前中の特別講演について非常に簡単にですがレポートしたいと思います。会場のルールとして発表中の撮影が禁止されていたため画像が皆無ですがご了承ください*1。エバンジェリスト話の流れとしては題にある通りre:inventというイベント全体の流れを説明して午後のテクニカルセッションを理解しやすくするためのものでした。全5日に渡るre:inventについて各曜日に何が行われたか、発表されたサービスなどの概要が説明されます。以下特に記憶に残っている点を書き出しました。人工衛星との連携や全世界規模の海底ケーブルプロジェクトへの参入awsがクラウド分野を開拓してからまだ12年ですが、いよいよ話が大きくなってきたなと思いました。この人工衛星との連携というのは受信側の話だそうですが、この分だとawsが自ら人工衛星を打ち上げる(そしてそれがサービスになる)のもそう遠くなさそうです。一部で物議を醸した開発者の代わりとなるビルダーという呼び方についての説明がありました。弁明めいて聞こえたのは僕の気のせいかもしれませんが、やはりビルダーという呼称はイマイチしっくり来ないなと感じました。新機能/サービス公開と顧客数が加速的に増加していることをアピール去年のre:inventと比べて今年はより多くの新機能を公開しているということでした*2。顧客数の増加もより加速しているそうです。その測定方法や詳しい値は一切公開されていなかった点は留意しましょう。DBに関してはOracle社にやり返すDBに関してはかなり面白い一幕がありました。Oracleでは顧客であるAmazonとOracleの関係は、最近Amazonが社内DBをOracleからRedshiftへ変更したことにより一気に冷え込みつつあるそうです。エンタープライズ今回の発表の中でも「ビルダーはプロダクトに不当に縛られるべきではない、どこの会社とは言わないが」という趣旨の発言がありました。DBについて話している途中出会ったことからもOracle社のことだったのは間違いないでしょう。Databaseに振り回された身としては個人的には大いに同意するところです。まとめ以上になります。短くはありますが軽く雰囲気だけでも掴んで頂ければ幸いです。この記事は2.5%ルールに従い業務時間を利用して書かれました。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。