この記事は本番環境でやらかしちゃった人のアドベントカレンダー２日目の記事です。 内容的にそろそろ時効だと思うので供養のために書きました。 追記。そういえば時期をちゃんと書いてなかったけど事件が起きたのは去年2018年、つまり仕込み（ヲイ）は2017年の話です ぶっちゃけネタ記事ですｗ （たまたま見つけて参加してみただけなのに昨日の記事の伸びっぷりを見て戦々恐々としてる TL;DR DB移行作業において、テスト期間中は常に最新のデータで処理できるように書いておいたプログラムをcrontabで実行していた。最終的に本番に合わせて日時を調整していたが、そのことを失念し１年後に再実行されてしまい、本番データが１年前に巻き戻る事故発生。 crontab は分、時、日、月、曜日を指定できるが、１年後に帰ってくるから気をつけてね。という話。 惨劇はなぜおこってしまったのか 結論から言えばcrontabの

この記事は「本番環境でやらかしちゃった人 Advent Calendar 2019」の1日目です。 https://qiita.com/advent-calendar/2019/yarakashi-production なかなか濃いラインナップが期待されますが、まずはさらっといきたいと思います。 具体性が乏しい部分もあると思いますが、そこはお察しください。。。 やらかし 背景（前提条件） いっていに昔の話です ETL（データ加工）サーバ 数十を超えるシステムからデータを集める BIツールなどで活用できるように各種加工処理を行い、DBなどにロードする 繁忙の違いはあれど、24/365で常時一定量の処理は稼働している 複数のチームが共存しているサーバ アプリ面では比較的疎 ETL処理のリリース前に本番サーバ上で試験をする取り決めになっていた 性能や本番相当データのテストが安全に行えるような環境

コメント欄で「Software Design 誌 (2018/12) に寄稿した内容や修正などをこちらの記事にも適用したい」と言ったあと、やるやる詐欺でずっと放置していましたが、三年近く経ってようやく 2021年 7月に大幅に改訂し、同時に Zenn に引っ越すことにしました。 タイムゾーン呪いの書 (知識編) タイムゾーン呪いの書 (実装編) タイムゾーン呪いの書 (Java 編) なにやら長くなりすぎたので三部構成になっています。 この Qiita 版は、しばらく (最低一年は) 改訂前のまま残しておきます。 タイムゾーンの存在はほぼ全ての人が知っていると思います。ソフトウェア・エンジニアなら多くの方が、自分の得意な言語で、タイムゾーンが関わるなにかしらのコードを書いたことがあるでしょう。ですが、日本に住んで日本の仕事をしていると国内時差もなく1 夏時間もない2 日本標準時 (Japa

この記事はなんなの プログラミングを始めたばかりで高速化の大枠が全くわからず意味不明なことをしていた在学時、こんな資料があったら良かったのになあ、と思って書いたもの。 書いて、在学時研究室に押し付けた後紛失したと思われていたものが発掘されたもの。 要約 ライブラリがあるならそれを使う。 ライブラリが無ければ、ボトルネック部分を探してそこだけ高速な言語で書きなおすか、可能なら事前コンパイルする。 最初から全てを Low-Level な言語で書くと大変、でも結果のプログラムは速い。 以下の時間の計測ではインポートにかかる時間は除いています。 使用するもの Python（3系） Numba Scipy Line Profiler Fortran（gfortran） QUADPACK QUADPACK以外の導入方法の説明は色んな所にあるので各自でお願いします。上3つに関しては、個人的にはAnaco

はじめに 趣旨 個人的にディープラーニングや機械学習を学習したいと思い、O'Reilly Japanさんから出版されているゼロから作るDeep Learningを読みました。 しかし、私自身に知識がなく、いまいちピンとこなかったので、簡単なものを作ってみようと考えました。 とはいえ、せっかくなら自分の趣味でもある麻雀に関わるところで作ろうと考えました。 筆者のスペック Python、機械学習ともに初心者 普段はPHPやRubyを使ったWebのお仕事 環境 Python 3.6.0 bottle 0.12.13 heroku 機能概要 作成したアプリは下記になります。 https://python-mahjang.herokuapp.com/index また、ソースコードは下記になります。 https://github.com/naoki85/python_mahjong 配牌と結果のみを学

まだgzipで消耗し（略） 2016年、人類が待ち望んでいた、gzipを圧倒するOSS圧縮ツールzstd(Zstandard)がリリースされたにも関わらず、なんかあんまり話題になっていなくて寂しいので、ちょろいかんじの賑やかし比較記事を書きました。圧縮ツールのカタログ的に眺めていただけるかと思います。 はじめに （この記事で言う）圧縮ツールとは何か 圧縮ツールという呼び名は正確ではない（はず）です。平たく言えば、gzipやbzip2、xz、lz4などですが、人によっては、tarの裏側としてしか使ってなくて、聞いたこともないかもしれませんね。そういうときはまずgzipのmanpageとか読んでください。 しかし、そういうツールを何と呼べばいいのかわからないので、ここでは圧縮ツールと呼んでいます。 ややこしいですが、アーカイバではありません。アーカイブとは実態が一つのファイルになっているフォル

<2018/03/08追記> 2018年3月、Lambda@Edgeを使った画像リサイズのソリューションがAWSの公式ブログにて紹介されました。 - Amazon CloudFront & Lambda@Edge で画像をリサイズする - Amazon Web Services ブログ 今後サーバレスな画像リサイズ処理について検討する場合は、上のブログ記事を参照されることをお勧めいたします。 </追記> 2016年11月に Amazon API Gatewayがバイナリデータに対応したので、Amazon CloudFront、AWS Lambda、Amazon S3を組み合わせて、フルマネージドな画像変換（リサイズ）APIを作ってみる。 やりたいこと URL中のパスで指定したファイルを、クエリパラメータで指定したサイズ（今回は幅のみ指定）に変換して返す。 例えば HTML中にimgタグで

Gyazo + Amazon CloudFront で簡単☆高速スクリーンショット共有 個人用の Gyazo 環境向けに、クライアントに手を入れて直接 Dropbox や S3 へスクリーンショットをアップロードするというテクニックがある。自前サーバを管理することなく利用できて大変ナイスなものの、クライアント側で比較的重要な固有情報を含んだ状態になっているので、取り扱いが若干難しいと思った。 そこで AWS Lambda を利用して、S3 へのアップロードを行う署名付き URL の発行をそちらで行い、クライアントでは受け取った情報だけでアップロード処理が進めれるような体制を作ってみた。 処理の流れと役割 スクリーンショットを撮る。 通常ならば Gyazo サーバへスクリーンショットをアップロードするところを、後述する AWS Lambda へ S3 アップロードのための署名付き URL を

こんにちは。 今回は、「VisualOps」という、書いた構成図から自動で構築してくれるツールを触ってみようと思います！ これぞクラウド！という感じがして、とてもテンションが上がるツールです。 昔は「Madeiracloud」という名前だったようです。 1.概要 さくっと概要ですが、VisualOpsでは、こんなことができます！！！ 構成図描いて... ローンチすると... AWS環境が自動で構築される！！！ さらに... 作成した構成図をPNG、JSON、CloudFormation用フォーマットで出力することもできます！！ AWSやエンジニア経験が浅い私にとっては夢のようなツールです！ 2.セットアップ それでは、実際に使っていきます！ VisualOpsのアカウントの登録からAWSのアカウントの紐付けまでやっていきます。 1.VisualOps公式サイトに接続し、[SignUpFre

はじめに AWS Lambdaが2016年2月11日に待望のVPCアクセスをサポートしてから1ヶ月とちょっと経ったわけですが、その特性や気をつける点については以前こちらで簡単にまとめました。今回は実際にVPCアクセスを利用しようとして上手く行っていない場合にチェックすべきポイントについて簡単にまとめます。 といっても基本的にはAWS Lambda固有の話ではなく、VPC周りの確認が主になります。 なお、VPCの件以外にもAWS Lambdaの挙動などハマりがちなポイント、確認すべきポイントについて先日のJAWS DAYS 2016で登壇した際にまとめたのでこちらも合わせて参照ください。 本投稿は個人によるものであり、所属する企業や団体に関係するものでも代表するものでもありません AWS Lambdaにおけるネットワーク的な制限 まず、AWS LambdaでVPCアクセスを有効にしたにも関わ

AWS SDKを利用してプログラミングをする際、クレデンシャル情報（アクセスキーとシークレットキー）をハードコードしたりGitHubにpushしたりしちゃダメよ、というのは当然だと思うんですが、じゃあどこに格納しておくのが正解なんだっけ？と悩んだのでまとめておきます。 検索の優先順位について AWS SDKを使ったプログラム中でアクセスキーなどが明示的に指定されていない場合、クレデンシャル情報は次の優先順位で検索されます。 環境変数AWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEY（.NET SDK以外） 設定ファイル~/.aws/credentials (Linux/Mac)または%USERPROFILE%\.aws\credentials (Windows) SDKごとの設定ファイル（後方互換性のため） SDKストア（.NET SDKのみ） （コードがEC2

AWS LambdaのVPC内リソースへのアクセスが可能になるアップデートが行われました。これは昨年のre:Inventで発表のみされていたものの、その時点ではまだ使えず非常に多くの人がそのリリースを待ち望んでいた機能です。基本的な内容はこちらのブログ記事を参照頂くとして、ここではいくつかキーとなるポイントを簡単に紹介したいと思います。 概要 ブログを読んでもらえばわかるのですが簡単に説明すると、これまでAWS LambdaのファンクションはVirtual Private Cloud(VPC)内にあってパブリックなIPを持っていないAWSリソースにはアクセスできませんでした。従ってAWS Lambdaからデータベースにアクセスしようとした場合にはデータベースサーバのIPアドレスやポートをパブリックにした上でアクセスを許可する必要がありました。一方でAmazon ElastiCacheのよう

注：本記事は個人によるものであり、所属する企業や団体に関係するものでも代表するものでもありません。 はじめに 先日、モバイル向けのバックエンドサービスであるParse.comが1年後に終了するという発表がされたのは記憶に新しいと思います。このニュースは多くの人に衝撃をもって受け止められました。 この発表のなかで、既存ユーザに対する救済処置としてデータベースの移行ツールとParse Serverのオープンソース化を発表しています。このParse Serverは発表中でParse APIとほぼ互換であるものであり、Node.jsで動くとしています。また、最新SDKでは自前のParse Serverへのリダイレクト機能が備わっているということですね。 というわけでこれをAmazon Web Services（AWS）で動かしてみたいと思います。AWSで動かすにあたって今回はAWS Elastic

https://medium.com/aws-activate-startup-blog/scaling-on-aws-part-1-a-primer-dbf1276ded5a の個人的な翻訳というかメモです。所属する企業や団体における公式見解ならびに公式発表ではございません。 スケールするオンプレミスのインフラストラクチャの実現は難しいと思います。ピークのキャパシティを見積もり、機器の到着を待ち、ハードウエアとソフトウエアのセットアップをし、全てが正しく稼働をすることを願う、、。 恐らくCloudにデプロイを行うことで、それらの頭の痛いことを解決できると聞いたことがあるでしょう。ということで、あなたのボスもしくはあなたはイロイロ物色した結果、AWSを試してみることになりました。 AWSのインフラストラクチャをプロパーにスケールさせるお仕事のはじまりです。まず来るべきScaling on

さだまさし 名詞-固有名詞-人名-一般 さだまさしの、主に詩の歌詞を対象に、簡単な品詞分解と、それを基にした簡単な分析を行ってみた、というのがこの記事の内容です。 個人的な最終的なゴールは、さだまさし風の歌詞を自動生成する bot (さだロボ) を作る事になりますが、その過程を週一でディアゴスティーニ的に（サダゴスティーニとかは節度のある大人なので言わない）書いていければと思います。 ついでに、その道すがら、ちょっとした解析・分析結果なども書いていきます。 道具の用意 解析するにあたっていくつか道具が必要なので、最初に、使用したツール群について簡単にお話します。 kuromoji KuromojiはJavaで書かれているオープンソースの日本語形態素解析エンジンです。 Java で形態素解析を行いたい場合、昔は「Sen」などを使うことが多かったですが、atilika 社が OSS として k

Embulk Advent Calendar 2015の1日目の投稿になります。 今年の9月にSoftware EngineerとしてTreasure Data(以下TD)に入社していた赤間(@oreradio)です。 最近はData Connector(後述)などの開発でJava/Rubyを書いています。 さて、OSSのバルクロードツールであるEmbulkが公開されて約1年が経ちました。 * 並列・分散処理、リトライ、リジューム等をサポートする * プラガブルな構造 * guessによる設定ファイル生成支援 * OSSとして公開されている などが特徴的な訳ですが、プラグインも90個近くが公開されOSSとして順調なスタートではないかと思います。 一方で本体やプラグインを含めた巨大なエコシステムをバルクロードという信頼性が求められる分野で全てOSSとして公開・メンテされる仕組みは果たして上手

日本国内でも随分使われるようになってきたSlack、みなさん随分使いこなしていると思うのですが、Slackも日々目まぐるしく進化してます。リリースを眺めたりするのが好きな筆者が「よく使う機能」や「これは便利だぞ」という機能を厳選して紹介します。 ※) 紹介しているのは、MacのクライアントAppを前提としています。 Slash Commands編 参照：Using slash commands – Slack Help Center みなさん、スラッシュコマンド使ってますか？ Slackでは殆どのことがスラッシュコマンドでできるといっても過言ではないくらい沢山のスラッシュコマンドがあります。ちょっと工夫すればオリジナルのスラッシュコマンドも作れるので楽しいですよ。 では、イチオシから紹介します１ リマインダー機能 たぶん、slackにリマインダー機能があることに気づいている人は少ないはず…

昨年、一部の方には好評を期したAWS LambdaのAdvent Calendarを今年もやります！ この一年でAWS Lambdaは大幅にアップデートしました。 ・GAローンチ ・Java対応 ・Python対応 ・スケジュール実行 ・タイムアウト時間延長 加えてVirtual Private Cloudへの対応も間もなく予定されています。 というわけで、よりできることの幅が広がったAWS Lambdaを使ったTips、ネタ、やってみた系なんでもOKなのでぜひご参加ください！ ちなみに、AWS Lambdaは以下のAWSサービスと簡単に連携できるようにもなっています。なのでこの辺りを駆使した何かを作ってみるのもいいですね！ ・Amazon S3 ・Amazon DynamoDB Streams ・Amazon Kinesis ・Amazon SNS ・Amazon Cognito ・Al

Redis不適切利用による問題は本番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100本くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... （この話は事実ではなくファンタジーです。） 深夜電話で叩き起こされました。どうやらアクセス障害みたいです。 何人かで実機確認したら、まったくゲームが遊べない。データ不整合怖いのでメンテIN。 ほどなくしてRedisが溢れメモリ不足で新規書き込みが出来なくなっていると判明。サーバのメモリ容量は64GByteでこれ以

というテーマで東京Node学園祭2015でセッションさせて頂くことになったので、先に整理/メモ的ななにかを。 （追記）以下資料で発表しました。 大規模Node.jsを支える ロードバランスとオートスケールの独自実装 http://www.slideshare.net/kidach1/nodejs-54841327 作ったもの ・スマホゲーム（マルチプレイアクション） 【公式】メザマシフェスティバル(メザフェス) | 株式会社アカツキ https://mezamashi-festival.aktsk.jp ・2D横スクロール ・マルチプレイ ・4人同時対戦 ・座標同期型 ・全国マッチング システム概要 Client： Cocos2d-x (c++) Server： API Server：Rails Websocket Server：Node.js 詳しくは スマホアプリにおけるマルチプレイア