Samsung SmartHome Team Makes Work-Life Balance a Reality for Engineers with MongoDB Atlas

MongoDB
January 23, 2024 | Updated: January 24, 2024

Businesses of all sizes, from early-stage startups to world-renowned enterprises, are challenged to build and deploy modern applications in today's rapidly changing digital landscape. And for the developers at the heart of these applications, it's a challenge to keep their applications up-to-date with the latest technologies while increasing their productivity.

At MongoDB.local Seoul in September 2023, Sungbin Im from Samsung Electronics' Digital Appliances (DA) division gave a talk titled "MongoDB Atlas brings work-life balance to evenings of DevOps engineer". In his presentation, Sungbin Im shared the real-world transformation in work efficiency that his team experienced by using MongoDB.

MongoDB Atlas for effective appliance data management

With Samsung's SmartThings at the center, Samsung Electronics' DA division has been developing a range of AI-powered home appliances and technologies for various services by leveraging the latest AI technology and the Internet of Things (IoT).

The SmartHome Service is the DA division's oldest and largest server platform, which collects device data from Samsung home appliances and makes it available for use in the division's various data-driven services.

Launched in 2014 as a user and device profile management server for controlling and monitoring Samsung home appliances with a mobile app, the Samsung SmartHome service managed application data on a MySQL database.

삼성전자 DA 사업부 임성빈 프로 — Sungbin Im, Samsung Electronics' DA division

In 2015, the team established a foundation to collect real-time event data generated by home appliances and use it for data-driven services, such as data for training AI services.

The team also introduced the community version of MongoDB, a document model for flexible processing and utilization of application data workloads in JSON format, bringing the power of NoSQL to the forefront of development workloads.

Building a strong foundation for scaling services

When the team first started using MongoDB, running the community version of MongoDB was a smooth process. But as the number of home appliances and the amount of traffic communicating with the server continued to grow, the team began to face challenges in keeping the service running reliably.

In particular, during the hot summer months, when the use of home appliances such as air conditioners and refrigerators increases, the data flowing into the server tends to be concentrated at certain times, compounding the difficulties.

The community version of MongoDB had the advantage of being able to be tuned according to the developer's intentions, but it also required developer time to manage and operate the database if issues arose.

Moreover, as the company expanded its services, the development team felt the need to secure a technical background to better utilize MongoDB, as well as flexible clusters and enhanced storage and monitoring. In 2022, Samsung Electronics' DA division made a full-scale migration to MongoDB Atlas to operate its SmartHome services more effectively.

Considering the limitations and downtime of each option, Samsung Electronics' DA division set a migration policy that utilized the Mongomirror utility for data migration to a private network.

"It was important for Samsung SmartHome to maintain a balance between infrastructure management and business logic development. By migrating to MongoDB Atlas, we were able to reduce the burden of infrastructure management and focus on application development and innovation," explained Sungbin Im, who led the migration project.

"The average response time on MongoDB Atlas was more than halved from 8ms to 3ms, and the disk read latency was reduced from up to 3s to 18ms, which significantly improved availability," stressed Sungbin Im. "What was even more dramatic for us as developers was that after migrating to MongoDB Atlas, we did not experience any problems or alerts due to database processing failures."

As such, MongoDB Atlas has played an important role in providing a solid foundation for the expansion of Samsung SmartHome services, allowing them to easily handle more data traffic.

Achieving both developer productivity and service quality

At its core, the Samsung Electronics SmartHome development team manages a write-intensive workload that constantly updates events for every state that occurs on a device, such as sensor changes from an air conditioner (temperature, humidity, etc.) or the opening and closing of a refrigerator.

After analyzing key performance indicators with the MongoDB Korea team, the DA division concluded that the scale-out strategy on the existing replica set would not be able to quickly update and manage the ever-increasing traffic and workload spikes, especially during the peak summer months.

After experiencing significant improvements from migrating to MongoDB Atlas, Samsung Electronics' DA division envisioned a new scale-out strategy on a sharded cluster to overcome write workload limitations with the existing Replica Set.

"By conducting workshops and proof of concept (PoC) with the MongoDB Korea team, we were able to identify problems in advance and complete the sharding process," explained Sungbin Im. "By setting up point-in-time recovery (PITR), we were able to effectively recover data if something went wrong during the sharding process."

After sharding, balancing has been improved by distributing 300-400 node connections per shard, compared to about 800 connections in the previous Replica Set, and the logical data size of MongoDB has been reduced from 82 GB to about 42 GB, enabling efficient workload operation. Disk IOPS were also reduced by nearly half from the previous level of 16-20k/s to 8-10k/s, improving disk utilization.

With zero database outages and high availability based on MongoDB Atlas, DevOps engineers at Samsung Electronics' DA division are experiencing work-life balance and focusing on developing new services for customers.

Having built an efficient and reliable infrastructure by migrating to MongoDB Atlas and sharding, Samsung Electronics DA Division plans to continue working with MongoDB Korea to manage data workloads more effectively in the future.

← Previous

MongoDB Security Incident Post Event Summary, January 23, 2024

MongoDB first informed customers in an alert posted on December 16, 2023 at 3:00pm EST that it was actively investigating a security incident involving unauthorized access to certain MongoDB corporate systems, which included exposure of customer account metadata and contact information. MongoDB posted updated information on www.mongodb.com/alerts as we continued to investigate the matter, notifying customers that our investigation was complete and closed in a post on January 3, 2024 at 5:00pm EST. During the investigation, we were able to confirm that the unauthorized party never had access to any MongoDB clusters – either on-premises or in MongoDB Atlas – and never penetrated the Atlas cluster authentication system. As a reminder, MongoDB Atlas cluster access is authenticated via a separate system from MongoDB corporate systems. On October 6, 2023, at approximately 11:45:00 UTC, a previously unknown flaw in a third-party application used by MongoDB staff enabled an unauthorized party to successfully phish and acquire the Single Sign-On (“SSO”) credentials and a corresponding Time-based One-Time Password (“TOTP”) from a MongoDB employee. The unauthorized party executed an Adversary-in-the-Middle (AitM) attack and used the credentials acquired from the phishing attack to access data in certain corporate applications. As described in our previous alerts and blog , this included access to corporate applications containing certain customer contact information and metadata. Within twenty-four hours after the initial intrusion on October 6, 2023, MongoDB’s standard session limits kicked in, and the unauthorized party lost access to our corporate applications, except for our corporate messaging application. Between December 12 and December 14, 2023, the unauthorized party used their access to the corporate messaging application to send additional targeted phishing messages to MongoDB employees from the initially compromised user account, which enabled them to regain access to MongoDB corporate applications for a limited time. On December 14, a MongoDB employee identified the fraudulent phishing messages sent by the unauthorized party in our corporate messaging application and notified the MongoDB security team. The MongoDB security team immediately enacted its incident response plan. MongoDB's investigation focused on determining the timeline of the event, the initial infection vector, and the number of impacted employees. With that information, MongoDB and our third-party forensics firm examined logs for all systems the attacker accessed and used this information to understand the breadth of the event. MongoDB took the following actions: Disabled the functionality in the third-party application that contained the flaw abused by the unauthorized party; Reset the credentials of all known and suspected compromised user accounts; Cleared active sessions of all known and suspected compromised user accounts; Examined the environment to fully understand the breadth and depth of the unauthorized party’s activity and to extract indicators of compromise; and, On an ongoing basis, we’re continuing to review and harden our security posture, including developing additional monitoring and alerts. We also strengthened our phishing-resistant, multi-factor authentication policies and continue to reiterate that customers should enforce phishing-resistant MFA, regularly rotate passwords, and remain vigilant for social engineering attacks. MongoDB’s investigation is complete and closed. Together with our third-party forensic experts, we can confirm that the unauthorized party no longer has access to our environment.

January 23, 2024

Next →

Introducing: Multi-Kubernetes Cluster Deployment Support

Resilience and scalability are critical for today's production applications. MongoDB and Kubernetes are both well known for their ability to support those needs to the highest level. To better enable developers using MongoDB and Kubernetes, we’ve introduced a series of updates and capabilities that makes it easier to manage MongoDB across multiple Kubernetes clusters. In addition to the previously released support for running MongoDB replica sets and Ops Manager across multiple Kubernetes clusters, we're excited to announce the public preview release of support for Sharded Clusters spanning multiple Kubernetes clusters (GA to follow in November 2024). Support for deployment across multiple Kubernetes clusters is facilitated through the Enterprise Kubernetes Operator. As a recap for anyone unaware, the Enterprise Operator automates the deployment, scaling, and management of MongoDB clusters in Kubernetes. It simplifies database operations by handling tasks such as backups, upgrades, and failover, ensuring consistent performance and reliability in the Kubernetes environment. Multi-Kubernetes cluster deployment support enhances availability, resilience, and scalability for critical MongoDB workloads, empowering developers to efficiently manage these workloads within Kubernetes. This approach unlocks the highest level of availability and resilience by allowing shards to be located closer to users and applications, increasing geographical flexibility and reducing latency for globally distributed applications. Deploying replica sets across multiple Kubernetes clusters MongoDB replica sets are engineered to ensure high availability, data redundancy, and automated failover in database deployments. A replica set consists of multiple MongoDB instances—one primary and several secondary nodes—all maintaining the same dataset. The primary node handles all write operations, while the secondary nodes replicate the data and are available to take over as primary if the original primary node fails. This architecture is critical for maintaining continuous data availability, especially in production environments where downtime can be costly. Support for deploying MongoDB replica sets across multiple Kubernetes clusters helps ensure this level of availability for MongoDB-based applications running in Kubernetes. Deploying MongoDB replica sets across multiple Kubernetes clusters enables you to distribute your data, not only across nodes in the Kubernetes cluster, but across different clusters and geographic locations, ensuring that the rest of your deployments remain operational (even if one or more Kubernetes clusters or locations fail) and facilitating faster disaster recovery. To learn more about how to deploy replica sets across multiple Kubernetes clusters using the Enterprise Kubernetes Operator, visit our documentation . Sharding MongoDB across multiple Kubernetes clusters While replica sets duplicate data for resilience (and higher read rates), MongoDB sharded clusters divide the data up between shards, each of which is effectively a replica set, providing resilience for each portion of the data. This helps your database handle large datasets and high-throughput operations since each shard has a primary member handling write operations to that portion of the data; this allows MongoDB to scale up the write throughput horizontally, rather than requiring vertical scaling of every member of a replica set. In a Kubernetes environment, these shards can now be deployed across multiple Kubernetes clusters, giving higher resilience in the event of a loss of a Kubernetes cluster or an entire geographic location. This also offers the ability to locate shards in the same region as the applications or users accessing that portion of the data, reducing latency and improving user experience. Sharding is particularly useful for applications with large datasets and those requiring high availability and resilience as they grow. Support for sharding MongoDB across multiple Kubernetes clusters is currently in public preview and will be generally available in November. Deploying Ops Manager across multiple Kubernetes clusters Ops Manager is the self-hosted management platform that supports automation, monitoring, and backup of MongoDB on your own infrastructure. Ops Manager's most critical function is backup, and deploying it across multiple Kubernetes clusters greatly improves resilience and disaster recovery for your MongoDB deployments in Kubernetes. With Ops Manager distributed across several Kubernetes clusters, you can ensure that backups of deployments remain robust and available, even if one Kubernetes cluster or site fails. Furthermore, it allows Ops Manager to efficiently manage and monitor MongoDB deployments that are themselves distributed across multiple clusters, improving resilience and simplifying scaling and disaster recovery. To learn more about how to deploy Ops Manager across multiple Kubernetes clusters using the Enterprise Kubernetes Operator, visit our documentation . To leverage multi-Kubernetes-cluster support, you can get started with the Enterprise Kubernetes Operator .

October 10, 2024