アソビューで精算システムやSREチームを担当している並木です。マイクラ歴3年になるのに、いまだに豆腐建築から抜け出せません。建築センスをください。・アソビューにJOIN元々銀行のシステムを担当していたこともありアソビューでは主に精算周りのシステムに関わらせていただいております。今回は、精算システムにおける計算処理の注意点などを書きたいと思います。※言語はCOBOLにて実装した場合のイメージとなります。ベタ打ち固定で記載している場合は全ての固定箇所に修正が必要になり、修正範囲の確認から修正、テストと掛かる工数も大きくなりがちです。このような例はミスも起こりやすく、「お金を取り扱うシステム」としてはよくない例となります。SYOUHIZEI~~実際に計算してみると150円のおにぎりの消費税を固定で8%税率で計算しそれを加算することで税込金額として算出。162円が計算結果となります。良い実装例レコードの構成イメージDBで料率を管理し、増税時に掛かる作業としては最新レコードの挿入(inesrt)直近レコードの終了日の更新(update)のみであり、このDBを呼び出している箇所全てに適用されるため影響範囲の特定も容易で、テストも機械的に実施できることになります。処理さえ忘れていなければ実際の計算処理には影響が出なくなります。¥108といった形で固定で出力している場合には、計算処理同様に最新の税率を取得して出力するなどの工夫が必要になります。キャッシュレスに先んじてペーパレスは事前に対応していることが多かったためそこまで大掛かりな回収は必要ではなかった認識でいます。軽減税率の場合のレシート出力については、政府からも対応例が出ていますね。https://www.gov-online.go.jp/tokusyu/keigen_zeiritsu/jigyosya/kubunkisai.htmlまとめいかがでしたでしょうか。今回は消費税のことにのみ触れていますが、法改正に関わるシステム改修に関して一部ではありますが、サンプルを記載してみました。昨今では法改正に関わるシステム改修がテレビなどでも取り沙汰されるようになりましたので「どんなことしてるんだろう?」の理解の一助になれば幸いです。最後に記載した内容について、開発と運用の責任者を募集中です!※COBOLは必須スキルではありません。アソビューにてバックエンドおよびSREを担当している寺岡(@toda_kk)と申します。お願いします!最近はリングフィットアドベンチャーをやり始め、スクワットをする度に「いいぞ!」「すごいぞ!」と褒められることで自己肯定感を高めています。はじめにさて、SREの業務というと、どの企業でも多岐にわたるかと思います。インフラアーキテクチャの設計および構築、モニタリング環境の整備、開発フローや運用業務の効率化......などなど、ビジネス上あまり目立たないけれど実は大事な役割を担っていたりします*1。Managerという機能を検証・導入した話を取り上げたいと思います。CLIを介してEC2インスタンスを管理するための機能です。IAMポリシーでアクセス制御を設定できるなど、セキュリティ面での向上が期待できます。その他、サービスの特徴や導入のメリットについては公式ドキュメントをご参照いただきたいのですが、多くの場合はEC2インスタンスに対するssh接続の代替となる機能として認識されることが多いのではないかと思います。弊社ではインフラリソースとしてAWSを利用しており、特に最近はECSやEKSの導入をはじめアプリケーションのコンテナ化を進めています。jarファイルを実行してアプリケーションを起動しているケースがあります*2。したケースでは、サービスの再実行やインフラリソースの整備などでインスタンスにsshして作業することが少なくありません。そんな中で、日々の業務のなかで下記の点で課題が発生していました。EC2インスタンスにssh接続するための秘密鍵の管理が必要になる。誰がどういった作業を実施したのかロギングしづらい。ssh認証の秘密鍵(pemファイル)の管理EC2インスタンスへのssh認証方式として、多くの場合はパスワードを使用する方式と公開/秘密鍵を使用する方式を用いると思います。ようなファイル形式で秘密鍵を使った認証を選択する場合が多いのではないでしょうか。どちらの方式を選択するにせよ、パスワードや秘密鍵をどのように管理するかというところが運用上の課題になるでしょう。秘密鍵をどういう単位で生成するのか、個々のインスタンスで別にするのか、VPC内で同一にするのかなど、さまざまな方針があると思います。いずれにせよ、どのインスタンスがどの秘密鍵とひもづくのか、またどの秘密鍵をどのメンバーに共有しているのかなどの管理が煩雑になりがちです。スタートアップ創業当初で限られたメンバーでサービス開発をしているフェーズあれば大きな問題にはならないかもしれませんが、サービスや組織が大きくなるに連れてセキュリティ面を強化することは必須の課題となってきます。したときに、ひとつの課題としてインスタンスにおける認証方法の管理という点が浮上してくることでしょう。作業のロギング(監査ログの取得)またセキュリティの強化を考えた場合、機密性(Confidentiality)を確実にすると共に責任追跡性(Accountability)を担保することも重要となってきます。そこで、インスタンス上でどのような作業を行ったのか、さらにいえば誰がどのような操作を行ったのか、という監査ログを取得することが必要になってくると思います。OSを動かしている場合もあるでしょう。このような場合も含めて、OS上の監査ログ取得の選択肢としてはさまざまな方針が考えられるかと思いますが、多くの場合はログの連携や確認が容易にできないといったケースもあるのではないでしょうか。Managerの検証および導入を行いました。今回の検証にあたっては下記の記事を大いに参考に実施しました*4。導入の手順は非常に簡単で、下記の3ステップを実施するだけで完了します。Manager自体の設定を行う。EC2インスタンスにIAMポリシーを設定する*5。Managerを使えるように設定を行います。今回はマネジメントコンソール上から設定する方法を紹介します。Manager自体の設定について手順は多くはありません。導入するだけなら、下記のように設定するだけでOKです。Managerの利用が可能となります。Managerからセッションを開始できるようにするための設定を行います。運用していることもあるかと思います。そのような場合は、新たにインストールしておく必要があります。Managerを利用するために必要となるIAMポリシーを設定します。いうロールにアタッチされています。Managerの機能を全て許可する設定になっているので本番適用するのは控えた方が良さそうです。Managerを導入するための最低限のIAMポリシーとしては、いろいろと試してみたところ下記のようになるようです。この記述を元に、用途に合わせて設定を変更していただくのが良いかと思います。Managerを導入するための手順は、上記で完了となります。Managerで実行した操作のログを取得する方法を紹介します。Managerの設定にある項目を有効化するだけ済みます。Logsにログ出力するように設定すると、指定したロググループに対してセッション終了後にログストリームが作成されます。Managerから作成されたログストリームの名前にはプレフィックスとしてIAMユーザー名が付きます。そのため、どのメンバーがどのような操作を実行したのかが簡単に追えるようになります。Logsに連携するように設定しましたが、設定画面にあるようにS3にログを送信することもできます。用途に応じて使い分けられると良さそうです。Logsに連携する場合はEC2インスタンスに設定するIAMポリシーに下記のような権限を加える必要があります。Logsに出力している場合が多いかと思いますので、特別にポリシーを変更する必要はないかもしれません。Managerを導入することで、はじめに挙げた2つの課題を解決することができました!まず、開発メンバーに対してpemファイルを配布する機会を減らし管理しやすくすることができました。新たに、ジョインしたメンバーに対しては、pemファイルを配布せずにEC2インスタンスの管理をお願いする準備を整えることができました。どのメンバーがEC2インスタンス上でどういった操作をしたのか記録できるようになりました。した形でセキュリティ面の強化を着実に進めることができたと思います。導入手順としては以上となりますが、弊社ではさらなる検証を実施しました。ひとつは、EC2インスタンスに設定するセキュリティグループについてです。上記の導入手順ではセキュリティグループの設定はありませんでした。Managerを介しEC2インスタンスへのセッションを開始するためのツールですが、今回の目的にどの程度適しているのかを検証してみました。Managerはsshの代替となるものではありますが、実際にはsshを実行しているわけではありません。開放する必要はありません。そこで、どの程度ポートを開けておく必要があるのか検証してみました。Manager経由で接続できます。Managerでも接続できませんでした。正確には、セッションは開始できるものの、出力を受け付けないためインスタンス上でなにが起きているのか把握できない状態となってしまっていました。Manager導入にあたって特別に設定変更する必要はないかと思います。Managerを利用する際にはマネジメントコンソールからセッションを開始します。ブラウザ上からコマンドを叩くのはぶっちゃけちょっと面倒ですし、人によってはつらい前世の記憶が呼び起こされることになるでしょう。いうツールが公式でサポートされています。Managerを利用できます。導入の手順などは公式ドキュメントをご参照ください。ツールのインストール後は下記コマンドを実行するだけでセッションを開始できます。[instance-id]これで全部ええやん!......と思いきや、ひとつ問題が発生しました。弊社ではAWSアカウントを複数所持しており、例えば本番環境と開発環境を分離するなどの目的でマルチアカウントで運用しています。そのため、マネジメントコンソールを利用する際には、まず大元となるAWSアカウントにログインして、そのあと別アカウントのロールとしてスイッチロールする形で運用しています。設定しており、IAMユーザーもそのように作成しています。そこで問題になるのがスイッチロールの際にはスイッチ元のIAMユーザー名は引き継がれないという点です。Logsに出力しており、ログストリームのプレフィックスにIAMユーザー名が付くことで監査ログとして機能できると考えていました。いう文字列が付与されてしまい、どのメンバーが操作したのか追いづらくなってしまいます。そのため、ログストリームにそのユーザー名が入るようになってしまっているようです*7。Managerの導入後にこのような問題が発覚してしまいました。Logsへのログ出力で十分と考えることもできます。Managerの導入と開発メンバーへの共有を進めました。Managerを導入することで、開発メンバーに対してpemファイルを配布する機会を減らし管理しやすくすることができました。新たに、ジョインしたメンバーに対してはpemファイルを配布せずにEC2インスタンスの管理をお願いする準備を整えることができました。どのメンバーがEC2インスタンス上でどういった操作をしたのか記録できるようになりました。した形でセキュリティ面の強化を着実に進めることができたと思います。いえ、手が足らずに思うように実行できていないのも事実です。そこで、下記の通り新たなメンバーを積極的に募集中ですので、ぜひ応募いただけると嬉しいです!hrmos.coみんなどんどん応募してくれよな!!*1:このアドベントカレンダーでもCloudFormationの話やEKSの話など、SREチームのメンバーが書いた記事がいくつかあります。*2:アソビューでは開発言語としてJavaを利用しているアプリケーションが多いです。Javaを選択する理由についてはこちらの記事をご参照ください。Linux上でauditdを使って監査ログを取得する際は、こちらの記事が参考になるかと思います。ナレコムAWSレシピ*4:クラスメソッド様、いつもありがとうございます!*5:正確には「IAMポリシーをアタッチしたIAMロールをインスタンスプロファイルとして設定する」ということになるでしょうが、記述の簡略化のため上記のように表現しています。*6:この辺りはまだしっかりと検証できていない部分です。私が調べた限りでは、この辺りの詳細について解説したページは見当たりませんでした。どなたかご存知の方がいらっしゃれば、ご教示いただけると助かります!*7:公式ドキュメントのこの辺りを参照すれば解決しそうな気がしますが、まだ十分に検証できていません。アソビュー株式会社でバックエンドエンジニアをしている土屋です。最近はスマブラにハマっており、大会に向けて日々練習中です。本記事の概要DBでデータを効率的に管理するためのテーブル構造と、そのメリット・デメリットを考えてみたお話です。背景アソビュー!では様々なデータをRDBで取り扱っていますが、テーブル構造はメンテナンスが難しいです。モノリシックなマスターテーブルが存在していて、更新日カラムが付属しているけどどこを更新したのかわからない。過去のデータがほしいけどマスターテーブルなので元々がどんなデータだったかわからない。いうことがたまに発生したりします。上記から履歴管理ができるテーブル構造を作る必要があったため、検討をしました。検証ショップと商品というデータの格納方法について、以下の2つの方法でメリット・デメリットを検討してみます。TABLEだけでOKになります1つのテーブル情報が肥大化しないので、変更容易性に富みますデータが独立しているので、nullのデータが入りにくいですデメリットテーブル数が増えるため、命名にルールがないと管理が大変になります履歴を管理するという要件の特性上、レコード数が膨大になりやすいですリビジョンを上げるタイミングなどは要件として考慮する必要がありますおわりに履歴管理を行うことで、どんな操作が行われたかわかるようになるので、利用者も開発者にも恩恵があると思っています。いえ不要なデータを管理する必要はないので、履歴管理の対象はどれなのかを都度検討できるとよいかなと思います。2019の15日目です。こんにちは、アソビューでBEエンジニアのThang(タン)です。Gatlingで負荷試験を試したので備忘録です。APIの負荷試験です。APIインタフェースはこちらでご参照して頂けます。インストールJDKが必要なので、インストールします。java公式HPからzipファイルをダウンロードします。2.3.1で試しました。gatling.shがあるので実行して、サンプルの負荷試験を実施してみます。bin/gatling.shシナリオを選択します。1のAdvancedSimulationStep01を選択してみましょう。実行完了され、結果が出力されます。結果はこんな感じです。シナリオを書いてみるgatlingはシナリオ自動生成機能を使っても良いのですが、今回は自分で1からシナリオを作成してみます。user-files/simulationsになります。conf/gatling.confのdirectory.simulations項目で変えられます。書いたシナリオはこんな感じです。postリクエストを送りますリクエストbodyはStringBodyを使って設定します。CSVファイルのデータを使って設定します。IFはこんな感じです。]}CSVファイルはこんな感じです。ファイルの置き場所はuser-files/dataになります。merchantId,serviceId,startSec,durationSec,ticketId,count,price149990,service0000001,1569805200,36000,0001,2,3200000000149990,service0000002,1569805200,36000,0002,2,3200000000149990,service0000003,1569805200,36000,0003,2,3200000000149990,service0000004,1569805200,36000,0004,2,3200000000149990,service0000005,1569805200,36000,0005,2,3200000000gatling.shを実行すると、シナリオ選択のところで今回書いたシナリオ(test)が追加されます。それを選択すると、追加シナリオを実行できます。