Hero Image
APIファーストについて

1.APIファーストについて 本システムは、マイクロサービス1をAPIで提供することをコンセプトに構築されています。APIファースト2の視点を取り入れることができれば、APIのURLごとに技術を変えたり、設計の統一ができるようになります。これによってメンテナンス性を向上させたり、マイクロサービス的な視点によってサービスの肥大化を防げるようになります。 2.システム構成 本システムでは、APIを利用することで各種サービスを要求に応じて追加提供できます。このために、バックエンドが複雑になっていますが各種監視まで細かな管理ができ信頼性のおけるシステムです。また、高速な通信技術と最新のセキュリティ技術を導入していますので優れたUXを提供しています。 また、開発・テスト・デプロイまで一連の作業が一部自動化されるなど見通しがよく使いやすい設計となっていますので、メンテナンスや拡張性に優れています。 バックエンドのGo言語は、並行処理や並列処理が言語レベルで備わっており、このCPUで複数の仕事を同時に行う機能により、大量の同時接続に対応できかつコンパイル型なので高速に処理することができます。 3.技術スタック フロントエンド 言語: Javascript フレームワーク: Svelte/Sapper バックエンド 言語: Go プラットフォーム: Micro データベース PostgreSql: リレーショナル データ ストレージ ArangoDB: マスタデータ用のマルチモデル Timescale: 高速時系列データベース Redis: キャッシュ用[Key-value]データベース オーケストレーション Docker KubernetesはMinikubeで動作します。 通信 gRPC: サービス間の高速な通信技術 JSON: データ記述言語 その他 NATS: Pub/sub NGINX: K8sの進捗コントローラ Vault: K8sのパスワード管理 Prometheus: モニタリングツール Grafana: データ可視化ツール 4.マイクロサービス 電子掲示板 SNS チャット SMS(プッシュ通知) アンケート(Google Formを使うが、連絡先のDB化) 広告掲載(SSHにて管理者が行う) API管理(アプリケーション管理)(システム管理者) メトリクス監視(1)(DB:PostgreSQL)(システム管理者) メトリクス監視(2)(DB:AngoraDB)(システム管理者) 以上 マイクロサービス:マイクロサービスとは、複数の独立した小さなコンポーネントやサービスの組み合わせによりアプリケーションを開発する、クラウドネイティブなアプローチのアーキテクチャーです。。 ↩︎ APIファースト:APIは、プログラム的な結び付きを使って他のコードにアクセスできるようにする仕組みです。これを利用するとソフトウェア開発に要する時間が根本的に短縮できます。また、ソフトウェア開発にAPIファーストのアプローチを取ればソフトウェア開発の作業を洗練できます。 ↩︎

Hero Image
Grafanaとは

1.Grafanaの概要 Grafanaのドキュメント Grafanaとは、Grafana Labs社が開発したデータ可視化ツールです。 Grafanaを利用するためには元のデータが必要であるため、データを収集するツール(PrometheusやElasticsearch等)と組み合わせて使われます。 可視化に特化しているため、他プロダクトが各自で用意しているダッシュボードよりも時系列グラフの可視化自由度が高いという特徴があります。 2.Grafanaの主な特徴 データのクエリ、視覚化、アラート、およびデータの保存場所に関係なく、データの理解を行います。Grafanaを使用すると、美しく柔軟なダッシュボードを通じてすべてのデータを作成、探索、共有できます。 データベースではなくデータを統合する 誰もが見ることができるデータ 誰でも使用できるダッシュボード 柔軟性と汎用性 3.Grafanaの動作環境 当社のローカルSNSの場合 AWS-EC2:Ubuntu20.04 Metrics監視(1)DB : PostgreSQL 4.Grafana機械学習1 Grafana機械学習は、Grafana Cloudユーザーがシステムの現在または将来の状態の予測を作成する機能を提供します。 予測を作成するには、ソース クエリ (モデル化する時系列) と機械学習モデルの構成を定義します。システムは、バックグラウンドでモデルをトレーニングします。 モデルのトレーニングが正常に完了したら、クエリを発行して、将来のさまざまな時間に系列の値を予測できます。モデルは予測値の信頼限界も返します。 時間が経つにつれて、モデルは新しいパターンを学習し続けるので、自動的にデータと共に進化します。 4-1.はじめに メトリック予測の動作を確認するには、概要チュートリアル[^16102]を参照してください。 クエリを実行すると、機械学習プロメテウスデータソースを使用してクエリを作成するのに役立ちます。 モデル構成では、モデルを調整して予測を改善する方法について説明しています。 4-2.手順 このガイドでは、Grafana Cloud のメトリクスの使用状況の予測を作成します。 この予測を使用して、制限を超えると予測される場合や、予想外に増加したメトリックが発生したかどうかを確認できます。 予測の作成 機械学習>予測に移動します。 [予測の作成] をクリックします。 クエリ ビルダで、データソースグラファナクラウドの使用状況を選択します。 次のクエリを実行します。sum(grafanacloud_instance_active_series) [トレーニング モデル] タブをクリックします。 ここで何かを調整する必要はありませんが、ノブがチューニング可能なものを見てください。 [予測の作成] をクリックします。 予測に名前を付け、[確認] をクリックします。 予測を表示 グラファナクラウドアクティブシリーズ予測の表示をクリックします。 ビューをキャストの興味深い時間枠に変更します。 予測が実際の結果とどのように一致するかを調べ、将来何日か含んで、モデルがアクティブなシリーズがどのように進化すると考えているかを確認してください。 パネルで予測を使用する ビューページから: 右上の [コピー] パネル ボタンをクリックします。 パネルにアラートを含めるには、[アラートを含める]を選択し、それ以外の場合は[アラートなし]を選択します。 既存のダッシュボードを開くか、新しいダッシュボードを作成します。 クリップボードからパネルを貼り付けてダッシュボードにパネルを追加します。 新しいパネルを編集し、生成されたクエリを表示します。 以上 Grafana機械学習 ↩︎

Hero Image
JamStackサイト制作手順

1.各種登録 カスタムドメイン登録サイト:例)Google Domain ソース管理サイト:例)Github,Gitlab アプリのビルド&デプロイ:例)Netlify ヘッドレスCMS:例)microCMS、Strapi(自分でクラウドに構築) 2.画面設計と文章・画像の準備 メインアイコン、faviconの作成 アイキャッチ画像の準備(wepb、svg、jpegなど) 顧客の準備できる画像の加工 基本的な顧客情報、商品などの説明 3.Hugoのテーマの選択 Hugoのテーマは、200以上あります。 当社では、「Hugo Serif」を採択しています。 4.HugoのインストールとGitHubへpush ローカルPCへHugoのテーマをインストールします。 当社では、WSLのUbuntu22.04となります。 GitHubへソースをpushします。 5.Hugoの各種設定と配置 基本的な設定をします 画像、文章を配置します。 6.ヘッドレスCMS ヘッドレスCMSは、お客様が必要な場合に準備します。 当社のサイトは、ローカルPCで編集したものをGitHubへpushしています。 ヘッドレスCMSのAPI連携を構築します。 小さな個人・法人サイトでは、microCMSは、無料で使えるの便利です。 Strapiは、ある程度のスペックが必要ですので注意が必要です。 弊社のサンプルアプリは、Strapiを使っています。 7.Netlifyへ連携 Netlifyは、Github,GitLabと簡単に連携できます。 カスタムドメインとSSLの設定をします。 「Google DomainのDNS」で事前にNetlifyのIPを設定しておきます。 8. デモアプリ Strapiを使ったサンプルアプリ(SQLite) Sveltekit×Render.com(Strapi)×Github×Netlify 以上

Hero Image
「MicroとgRPC」について

ローカルSNSで使っている【MicroとgRPC】 ローカルSNSで使っており、便利な技術です。 Go-Microは、基盤となるプラットフォームがそれらを記述するために必要なプリミティブを定義し、外部の手段からアクセスするために必要なプリミティブを定義する理由である、このサービス開発モデルを念頭に置いて構築されています。Micro には、高速での使用が非常に簡単になる Go サービス フレームワークが含まれています。 本システムを構成するために使われており、カスタマイズに必要なアプリケーションについて説明します。全体は、microサービスで構成されており、gRPCアプリケーションの各サービスと技術について説明します。 クラウドサービスの定義は、次のTwilioまたはStripeを構築するのに役立つものと考えています。クラウドサービスは、APIとして完全に消費されるように構築されたもののようにますます見ています。だから、マイクロは、そのモデルを念頭に置いて構築します。バックエンドにマイクロサービスを記述し、フロントエンドの単一の API としてそれらをつなぎ合わせます。 マイクロは、HTTP/JSON 要求を外部で処理し、バックエンド用に gRPC に変換する API ゲートウェイを提供します。これにより、バックエンドで効率的にパフォーマンスの高いサービスを構築し、相互に切り離されるが、消費者に単一のビューを提示するエクスペリエンスが大幅に簡素化されます。 Microは、マルチ環境モデルに存在するだけでなく、最初にリモートモデルに存在するという知識を持って構築されました。そのため、CLI とローカル サービスの gRPC ID プロキシを構築し、任意の Micro サーバーにリモートで安全に接続し、認証サービスに格納されている資格情報を使用してそれらのサービスとリソースにアクセスできるようにします。 サービスはクラウドの第 1 時代に合わせて構築されているだけでなく、サービスへのアクセスもそのようにしていると考えることができます。 M30 - M3OはMicroを搭載した次世代クラウドプラットフォームです。10 倍の開発者エクスペリエンスを実現するために、1 つのプラットフォーム上で、より簡単なプログラム可能なビルディング ブロックとして、無料で有料の公開 API を探索、発見、消費します。 プログラム可能な実世界マイクロサービスのレシピ - マイクロサービスは、あらゆる製品、アプリ、サービスの基本的な構成要素を提供します。これらは、単独で使用することも、組み合わせて強力な分散システムを作成することもできます。サービスは、RPC を使用して相互に使用され、Micro API を介して外部の世界から使用されることを意図しています。 参考資料 Go Micro - Go Microは分散システム開発のフレームワークです Micro Services - プログラム可能な実世界マイクロサービス Micro - マイクロは分散型クラウドオペレーティングシステムです。 Micro Document - マイクロへの高レベルの説明 M30 Micro Platform - Next Generation Cloud - 10 倍の開発者エクスペリエンスを実現するために、単純なプログラム可能なビルディング ブロックとしてパブリック API を 1 つのプラットフォームで探索、検出、使用します。 マイクロサービスフレームワークGo-Microを使う前にgRPCが必要になりますので、gRPCからGo-Microと進みます。

Hero Image
文書の管理

1. はじめに 1-1. 文書のペーパレス化の課題 業務 業務ノウハウを蓄積し活用したい 関係者が流用できる文書のひな型をデータベース化したい ひな型を作るルールを標準化したい ペーパレス化したい 検索ができるようにしたい 担当者のみが詳細を把握している状態の属人化をできるだけ避けたい。 同じような文書を担当者が変わる度に作成する無駄をなくしたい。 ブラウザがあれば業務が完了できるようにしたい 遠隔地からも同じ作業ができるようにしたい 様式美のためにやっている文書作成作業を軽減したい 部署毎の文書作成ローカルルールをなくしたい 文書作成コストを下げたい Word、Excelの課題 Word、Excelがないと読めない バージョン管理がしにくい 共同編集がしにくい 装飾と文章構造が分離されていない 差分が見にくい 機械可読性に欠ける 検索が難しい 大量の文書管理がファイルベースとなり管理が難しい ファイルの所在さえも担当者以外わからないことが多い。 同じような文書を何度も作成している。 文書の内容が多いと文書自体の装飾や編集に時間がかかります。 PDFの課題 スマートフォンで読みにくい 検索性が乏しい 編集できない バージョン管理がしにくい 再利用しにくい 機械可読性に欠ける 1-2. 構造化テキスト(Markdown形式1) マークダウン形式の文書で保管することのメリット 文章構造と表示部分が分離された軽量なフォーマットになります。 手軽にドキュメントを装飾できるフォーマットが使えます。 このことにより、流通性が高まり、部署、場所をまたいで利用できるようになります。 ファイルをダウンロードすることなく、多くの人の目に届けられる。 ファイルをメール等で送付することなく修正・校正、コメントなどフィードバックを得やすくすることが可能 システム化が簡易になります。このことにより以下のメリットがあります。 文書管理が簡単になり、属人化が避けることで文書資産を幅広く活用できます。 部署などの文書作成のローカルルールが公開することで誰もが理解できるパブリックなルールとなります。 検索が可能となり、文書の作成時に利用できる。 ブラウザ上で閲覧可能となります。 画像、動画などの管理もシステムで管理・共有・流用できます。 マークダウンは、PDFやHTMLへも変換は容易にできます。 共同編集が可能1となります。 文書の履歴管理ができるようになり、最新版の様式をいつも使えます。 レビューやコメント機能が使えます。 既存のWord文書内容の流用ができます。 マークダウン形式の文書で保管することのデメリット 管理するためには、やはりシステムが必要 マークダウン形式の文書作成に統一するコンセンサスが得られるか(これが最も難しい) 2. システム開発 前章で求められる機能を実現できるシステムは、どのようなものかまとめます。 2-1. 要件 文書の構文が、自由に作成 文書の構文をもとに作成された文書(ページ)は、この単位でマークダウンファイルとして保存 文書の編集は、公開・非公開、部署・担当者・業者、プロジェクト毎に閲覧・編集権限の管理 全文検索かつ検索結果の制限 ブラウザ上で閲覧・編集 画像(写真)、動画などの管理もシステムで管理・共有・流用 マークダウンは、PDFやHTMLへも変換 共同編集が可能1 履歴管理 レビューやコメント機能 既存のWord文書内容の流用 地方の県レベルで、毎年最低10万ページ作成可能(システムの拡張性) 同時アクセスが1万件程度 公開・非公開、部署・担当者・業者、プロジェクト毎に閲覧・編集権限の管理 データの暗号化 2-2.